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内 容 简 介 


Kubernetes 是 容器 编排 引 敬 的 事实 标准 ， 是 继 大 数据 、 云 计算 和 Docker 
之 后 又 一 热门 技术 ， 而 且 未 来 相当 一 段 时 间 内 都 会 非常 流行 。 对 于 IT 


行业 来 说 ， 这 有 征 一 项 非常 有 价值 的 技术 。 对 于 IT 从 业者 来 说 ， 掌 握 容 
絮 技 术 既 是 市 场 的 需要 ， 也 是 提升 目 我 价值 的 重要 途径 。 


本 书 共 C153, 系统 介绍 了 Kubernetes 的 架构 、 重 要 概念 、 安 装 部 署 方 

法 、 运 行 管理 应 用 的 技术 、 网 络 存储 管理 、 集 群 监控 和 日 志 管 理 等 重 

书 中 通过 大 量 实 操 案 例 深入 浅 出 地 讲解 Kubernetes 核 心 技 

术 ， 是 一 本 从 入 门 到 进 阶 的 实用 Kubernetes 操 作 指 导 手 册 。 读 者 在 学 

习 的 过 程 中 ， 可 以 跟着 教程 进行 操作 ， 在 实践 中 掌握 Kubernetes 的 核 

aa 则 可 以 将 本 教程 作为 参考 书 ， 按 需 查 找 相 
HAR E 


本 书 主要 面向 微服 务 软件 开发 人 员 ， 以 及 IT 实 施 和 运 维 工 程 师 等 相关 
人 员 ， 也 适合 作为 高 等 院 校 和 培训 学 校 相关 专业 的 教学 参考 书 。 
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写 在 最 前 面 


《每 天 5 分 钟 玩 转 Kubernetes》 是 一 本 系统 学 习 Kubernetes 的 教程 ， 有 
下 面 两 个 特点 : 


。 系统 讲解 当前 最 流行 的 容 絮 编排 9| 警 Kubemetes 


包括 安装 部 署 、 应 用 管理 、 网 络 、 存 全、 监控 、 日 志 管 理 等 多 个 


。 重 实践 并 兼顾 理论 
通过 大 量 实验 和 操作 市 领 大 家 学 习 Kubernetes。 
为 什么 要 写 这 个 
因为 Kubernetes 非 常 热 门 ， 但 学 习 门 槛 高 
2017 年 9 月 ，Mesosphere 宣 布 文 持 Kubernetes; k Docker 宣 布 将 在 


新 版 本 中 加 入 对 Kubernetes 的 原生 文 持 。 至 此 ， 容 中 ds Ja HF 5| SE SURE 
三 足 风 立时 代 结 束 ，Kubernetes 赢 得 全 面 胜 利 。 


其 实 早 在 2015 年 5 月 ，Kubernetes 在 Google 上 的 搜索 热度 职 已 经 超过 了 
Mesos 和 Docker Swarm， 从 那 之 后 便 是 一 路 诡 升 ， 将 对 手 “ 甩 开 了 十 几 


AA 
条 街 ”。 


目前 ，AWS、Azure、Google、 阿 里 云 、 腾 讯 云 等 主流 公有 云 提供 的 是 
基于 Kubernetes 的 容器 服务 » Rancher ^ CoreOS ` IBM ` Mirantis ^ 
Oracle ` Red Hat、VMWare 等 无 数 厂 丙 也 在 大 力 人 研发 和 推广 基于 
Kubemetes 的 容器 CaaS 或 PaaS 产 品 。 可 以 说 ，Kubernetes 是 当前 容器 行 
业 最 热门 的 。 


每 一 轮 新 技术 的 兴起 ， 无 论 对 公司 还 是 个 人 既是 机 会 也 是 挑战 。 这 项 
新 技术 未 来 必 将 成 为 主流 ， 那 么 作为 开 从 业者 ， 正 确 的 做 法 就 是 尽快 
掌握 2 因为 : 

(1) 新 技术 意味 着 新 的 市 场 和 新 的 需求 。 初 期 掌握 这 种 技术 的 人 不 是 
很 多 ， 而 市 场 需求 会 越 来 越 大 ， 因 而 会 形成 供不应求 的 卖方 市 场 ， 物 
以 稀 为 贵 ， 这 对 技术 人 员 将 是 一 个 难得 的 价值 提升 机 会 。 

(2) 学 习 新 技术 需要 时 间 和 精力 ， 早 起 步 早 成 材 。 

机 会 讲 过 了 ， 虽 们 再 来 看 看 挑战 。 
新 技术 往往 意味 着 技术 上 的 突破 和 创新 ， 会 有 不 少 新 的 概念 和 方法 。 
对 于 Kubernetes 这 项 平台 级 技术 ， 禾 盖 的 技术 范围 非常 广 ， 包 括 计 


算 、 网 络 、 和 存储、 高 可 用 、 监 控 、 日 志 管 理 等 多 个 方面 ， 要 和 掌握 这 些 
新 技术 对 IT 老兵 尚 有 不 小 难度 ， 更 别 说 新 人 了 。 


写 给 谁 看 
这 套 教 程 的 目标 读者 包括 ; 


IT 实施 和 运 维 工程 师 


越 来 越 多 的 应 用 将 以 容器 的 方式 在 开发 、 测 斌 和 生产 环境 中 运行 。 掌 
ae oie eee E 
心 竞 o 


软件 开发 人 员 

基于 容器 的 微服 务 架 构 (Microservice Architecture) 会 逐渐 成 为 开发 应 
用 系统 的 主流 ， 而 Kubernetes 将 是 运行 微服 务 应 用 的 理想 平台 ， 市 场 
将 需要 大 量具 备 Kubernetes 技 能 的 应 用 程序 开发 人 员 。 

我 自己 

CloudMan 坚 信和 最 好 的 学 习 方 法 是 分 讲 。 编 写 这 本 教程 的 同时 也 是 对 自 


己 学 习 和 实践 Kubernetes 技 术 的 总 结 。 对 于 知识 ， 只 有 把 它 写 出 来 并 
能 够 让 其 他 人 理解 ， 才 能 说 明 目 己 真正 掌握 了 。 


ae 


2018 年 1 月 


第 1 章 ” 先 把 Kubernetes 跑 起 来 


Kubernetes (K8s) 是 Google 在 2014 年 发 布 的 一 个 开源 项 目 。 


据说 Google 的 数据 中 心里 运行 着 20 多 亿 个 容器 ， 而 且 Google 十 年 前 就 
开始 使 用 容 恬 技术 。 


最 初 ，Google 开 发 了 一 个 叫 Borg 的 系统 (现在 命名 为 Omega) 来 调度 
如 此 庞大 数量 的 容 絮 和 工作 人 负载。 在 积 素 了 这 么 多 年 的 经 验 后 ， 
Google 决 定 重 写 这 个 容 右 管理 系统 ， 并 将 其 页 献 到 开源 社区 ， 让 全 世 
FEBRES ° 


XAT H Wæ Kubernetes ° WAH, Kuberneteszé Google Omega 的 开 
源 版 本 。 


从 2014 年 第 一 个 版 本 发 布 以 来 ，Kubermetes 迅 速 获 得 开源 社区 的 追 
$, &f&Red Hat、VMware、Canonical 在 内 的 很 多 有 影响 力 的 公司 加 
入 到 开发 和 推广 的 阵营 。 目 前 Kubernetes 已 经 成 为 发 展 最 快 、 市 场 占 
A Sac ie ae ES SET" m 


Kubernetes — EE" PORHUT RINER ° 本 书 我 们 将 以 v1.7 和 vl. 87 3 fi 
学 习 Kubernetes。 我 们 会 论 Kubernetes 重 要 的 概念 和 架构 ， 学 习 
Kubernetes 如 何 编排 容器 ， 包 括 优化 资源 利用 、 高 可 用 、 滚 动 更 新 、 
网 络 插件 、 服 务 发 现 、 监控 、 数据 管理 、 日 志 管 理 等 。 


下 面 就 让 我 们 开始 Kubemetes 的 探险 之 旅 。 


1.1 ” 先 跑 起 来 


按照 一 贯 的 学 习 思 路 ， 我 们 会 在 最 短 时 间 内 搭建 起 一 个 可 用 系统 ， 这 
样 束 能 够 尽快 建立 起 对 学 习 对 象 的 感性 认识 。 先 把 玩 起 来 ， 快 束 了 解 
基本 概念 、 功 能 和 使 用 场景 。 


el RAWAL, ibe RAI AS) AAR MRE RE 
RF EEC ATA, RADIAT BUF ° 


当然 ， 要 搭建 这 么 一 个 可 运行 的 系统 通常 也 不 会 太 容易 ， 不 过 很 笠 
运 ，Kubernetes 官 网 已 经 为 大 家 准备 好 了 现成 的 最 小 可 用 系统 。 


kubernetes.io 开 发 了 一 个 交互 式 教程 ， 通 过 Web 浏 览 絮 束 能 使 用 预先 部 
署 好 的 一 个 Kubernetes 集 群 ， 快 速 体验 Kubernetes 的 功能 和 应 用 场景 ， 
下 面 我 束 囊 着 大 家 去 玩 一 下 。 


J JFhttps://kubernetes.io/docs/tutorials/kubernetes-basics/ ° 


页 面 左 边 束 能 看 到 教程 菜单 ， 如 图 1-1 所 示 。 


kubernetes 


Tutorials 


v Kubernetes Basics 

Overview 

1. Create a Cluster 

2. Deploy an App 

3. Explore Your App 

4. Expose Your App Publicly 
5. Scale Your App 

6. Update Your App 


图 1-1 


教程 会 指引 大 家 完成 创建 Kubernetes 集 群 、 部 署 应 用 、 访 问 应 用 、 扩 
展 应 用 、 更 狐 应 用 等 最 种 见 的 使 用 场景 ， 迅 速 建 立 感性 认识 。 


1.2 ”创建 Kubernetes 集 和 群 


A4 uk SERIES. Create a Cluster > Interactive Tutorial - Creating a 
Cluster， 如 图 1-2 所 示 。 


kubernetes 


Tutorials 
v Kubernetes Basics 
Overview 
v 1.Create a Cluster 
Using Minikube to Create a Cluster 
Interactive Tutorial - Creating a Cluster 
> 2. Deploy an App 
> 3. Explore Your App 
> 4. Expose Your App Publicly 
> 5. Scale Your App 
> 6. Update Your App 


图 1-2 


显示 操作 界面 ， 如 图 1-3 所 示 。 


Terminal + 
Module 1 
Kubernetes Bootcamp Terminal 


Step 1 of 3 - 


>l 


Cluster up and 
running 


We already installed minikube for 
you. Check that it is properly 
installed, by running the minikube 
version command: 


minikube version e 


OK, we can see that minikube is in 
place. 


Start the cluster, by running the 
minikube start command: 


minikube start e 


Great! You now have a running 

Kubernetes cluster in your online 

terminal. Minikube started a virtual 

machine for you, and a Kubernetes f ““ Kata<oda 
C now Dnning 


n that VM 


图 1-3 
左边 部 分 是 操作 说 明 。 右 边 是 Terminal， 即 命令 终端 窗口 。 


按照 操作 说 明 ， 我 们 在 Terminal 中 执行 minikube start， 然 后 执行 kubectl 
get nodes, 这 样 束 创建 好 了 一 个 单 节点 的 kubernetes 集 群 ， 如 图 1-4 所 
ZN o 


Terminal 中 


Kubernetes Bootcamp Terminal 
> 


> minikube start 
Starting local Kubernetes cluster... 


> kubectl get nodes 
NAME STATUS AGE 
host01 Ready 7s 


> hostname 
e968725c1697 


> 


图 1-4 


集群 的 唯一 节点 为 host01， 需 要 注意 的 是 当前 执行 命令 的 地 方 并 不 是 
host01。 我 们 是 通过 Kubernetes 的 命令 行 工 具 kubectl 远 程 管理 集群 。 


执行 kubectl cluster-info 查 看 集群 信息 ， 如 图 1-5 所 示 。 


> kubectl cluster-info 
Kubernetes master is running at http: //host01: 8080 
heapster is running at http://host01:8080/api/v1/proxy/namespaces/kube-system/serv edic 
kubernetes-dashboard is running at http://host01:8080/a api /v1/proxy/ Ei say it ey es/kubernete: shboard 
monitoring-grafana is running at http://host@1:8080/api/v1/proxy/na aces/kube- i 
monitoring-influxdb is running at http://host01:8080/api/v1/proxy/n erie: selina pt cel: pude 


To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. 


图 1-5 
heapster、kubernetes-dashboard 都 是 集群 中 运行 的 服务 。 


注意 : 为 下 省 篇 幅 ， 在 后 面 的 演示 中 ， 我 们 将 简化 操作 步 又， 详细 的 
说 明和 完整 步骤 请 参考 官网 在 线 文档 。 


1.3 ”部 署 应 用 


kubectl run kubernetes-bootcamp \ 
- -image-docker.io/jocatalin/kubernetes-bootcamp:vi \ 


- -port-8080 


这 里 我 们 通过 kubectl rn 部 署 了 一 个 应 用 ， 命 名 为 kubernetes- 
bootcamp， 如 图 1-6 所 示 。 


Docker 镜 像 通过 --image 指 定 。 
--port 设 置 应 用 对 外 服务 的 端口 。 


Terminal + 


> kubectl run kubernetes-bootcamp \ 
> ——image=docker.io/jocatalin/kubernetes—bootcamp:v1 \ 


> —-port-8080 
deployment "kubernetes-bootcamp" created 


di. 


图 1-6 
这 里 Deployment 是 Kubernetes 的 术语 ， 可 以 理解 为 应 用 。 
Kubernetes 还 有 一 个 重要 术语 Pod ° 


Pod 是 容器 的 集合 ， 通 第 会 将 紧密 相关 的 一 组 容 右 放 到 一 个 Pod 中 ， 同 
E E ERE AIPA Ripon s 间 ， 也 就 是 说 它们 在 一 个 


network namespace 中 。 


ere ee E] — Pod "F B Zt si 48 2 8C ES Vj] 


运行 kubectl get pods， 查 看 当前 的 Po0d， 如 图 1-7 所 示 。 


> kubectl get pods 
NAME READY STATUS RESTARTS AGE 


kubernetes-bootcamp-390780338-q9p1t 1/1 Running 0 11m 


> 


图 1-7 


kubernetes-bootcamp-390780338-q9plt 就 是 应 用 的 Pod ° 


1.4 访问 应 用 


默认 情况 下 ， 所 有 Pod 只 能 在 集群 内 部 访问 。 对 于 上 面 这 个 例子 ， 要 

访问 应 用 只 能 直接 访问 容器 的 8080 端 口 。 为 了 能 够 从 外 部 访问 应 用 ， 

我 们 需要 将 容器 的 8080 端 口 映 射 到 节点 的 端口 。 

执行 如 下 命令 ， 结 果 如 图 1-8 所 示 。 

kubectl expose deployment/kubernetes-bootcamp \ 
--type="NodePort" \ 


--port 8080 


> kubectl expose deployment/kubernetes-bootcamp V 
> --type-"NodePort" X 
> —-port 8080 


service "kubernetes—bootcamp" exposed 


> 


图 1-8 


执行 命令 kubectl get services, ， 可 以 查看 应 用 被 映射 到 万 点 的 哪个 端 
口 ， 如 图 1-9 所 示 。 


> kubectl get services 
NAME CLUSTER-IP — EXTERNAL-IP PORT(S) 
kubernetes 10.0.0.1 «none» 443/TCP 


kubernetes—bootcamp 10.0.0.131 <nodes> 8080:32320/TCP 1m 


> 


图 1-9 


这 里 有 两 个 service， 可 以 将 service 暂 时 理解 为 端口 映射 ， 后 面 我 们 会 
详细 讨论 。 

Kubernetes 是 默认 的 service， 和 暂时 不 用 考虑 。kubernetes-bootcamp 是 我 
们 应 用 的 service，8080 端 口 已 经 映射 到 host01 的 32320 端 口 ， 端 口号 是 
随机 分 配 的 ， 可 以 执行 如 下 命令 访问 应 用 ， 结 果 如 图 1-10 所 示 。 


curl host01:32320 


> curl host@1:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-q9p1t | v=1 


> 


图 1-10 


1.5 Scale HH 


默认 情况 下 应 用 只 会 运行 一 个 副本 ， 可 以 通过 kubect] get deployments 
查看 副本 数 ， 如 图 1-11 所 示 。 


> kubectl get deployments 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 


kubernetes-bootcamp 1 1 1 al 14m 


> 


图 1-11 
执行 如 下 命令 将 副本 数 增加 到 3 个 ， 如 图 1-12 所 示 。 


kubectl scale deployments/kubernetes-bootcamp --replicas=3 


> kubectl scale deployments/kubernetes-bootcamp —-replicas=3 
deployment "kubernetes-bootcamp" scaled 


> 


> kubectl get deployments 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
kubernetes-bootcamp 3 3 3 3 17m 


> 


图 1-12 


通过 kubectl get pods 可 以 看 到 当前 Pod 增 加 a 到 3 个 ， 如 图 1-13 所 示 。 


> kubectl get pods 
NAME STATUS RESTARTS 
kubernetes-bootcamp-390780338-12sbg Running 0 
kubernetes-bootcamp-390780338-q9p1t Running 0 
kubernetes-bootcamp-390780338-swvp7 Running 0 


> 


图 1-13 


通过 cun 访 问 应 用 ， 可 以 看 到 每 次 请 求 发 送 到 不 同 的 Pod，3 个 副本 轮 
询 处 理 ， 这 样 束 实 现 了 负载 均衡 ， 如 图 1-14 所 示 。 


> curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-12sbg | 


> curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-swvp7 | 


> curl host01:32320 


Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-q9p1t | v=1 


> curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-12sbg | 


> 


图 1-14 
要 scale down 也 很 方便 ， 执 行 下 列 命令 ， 结 果 如 图 1-15 所 示 。 


kubectl scale deployments/kubernetes-bootcamp --replicas=2 


> kubectl scale deployments/kubernetes-bootcamp --replicas-2 
deployment "kubernetes-bootcamp" scaled 


» kubectl get deployments 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
kubernetes-bootcamp 2 2 2 2 25m 


> kubectl get pods 
NAME STATUS 
kubernetes-bootcamp-390780338-12sbg Running 
kubernetes-bootcamp-390780338-q9p1t Running 
kubernetes-bootcamp-390780338-swvp7 Terminating 


RESTARTS 


图 1-15 
从 图 1-15 中 可 以 看 到 ， 其 中 一 个 副本 被 删除 了 。 
16 ”滚动 更 新 
当前 应 用 使 用 的 image 版 本 为 v1， 执 行 如 下 命令 将 其 升级 到 v2， 结 果 如 
图 1-16 所 示 。 
kubectl set image deployments/kubernetes-bootcamp 


kubernetes-bootcamp=jocatalin/kubernetes- bootcamp: v2 


> kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp-jocatalin/kubernetes-bootcamp:v2 
deployment "kubernetes-bootcamp" image updated 


» kubectl get pods 


NAME 
kubernetes-bootcamp-2100875782-2q5k8 
kubernetes-bootcamp-2100875782-sbwkc 
kubernetes-bootcamp-390780338-12sbg 
kubernetes-bootcamp-390780338-q9p1t 


> kubectl get pods 
NAME 
kubernetes-bootcamp-2100875782-2q5k8 
kubernetes-bootcamp-2100875782-sbwkc 
kubernetes-bootcamp-390780338-12sbg 
kubernetes-bootcamp-390780338-q9p1t 


> kubectl get pods 
NAME 
kubernetes-bootcamp-2100875782-2q5k8 
kubernetes-bootcamp-2100875782-sbwkc 


> 


STATUS 


RESTARTS 


ContainerCreating 0 
ContainerCreating 0 
Terminating 0 
Running 0 


STATUS RESTARTS AGE 
Running 0 15s 
Running 0 13s 
Terminating @ 19m 
Terminating 0 37m 


STATUS RESTARTS 
Running 
Running 0 


图 1-16 


通过 kubect get pods 可 以 观察 滚动 更 新 的 过 程 : v1 的 Pod 被 逐个 删除 ， 
同时 局 动 了 新 的 v2 Pod。 更 新 完成 后 访问 新 版 本 应 用 ， 如 图 1-17 所 
ZN o 


» curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-2100875782-sbwkc | v=2 


> curl host01:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-2100875782-2q5k8 | v=2 


- 


图 1-17 


如 果 要 回 退 到 v1 版 本 也 很 容易 ， 执 行 kubectl rollout undo 命 令 ， 结 果 如 
图 1-18 所 示 。 


kubectl rollout undo deployments/kubernetes-bootcamp 


> kubectl rollout undo deployments/kubernetes-bootcamp 
deployment "kubernetes-bootcamp" rolled back 


> kubectl get pods 
NAME STATUS RESTARTS 
kubernetes-bootcamp-2100875782-2q5k8 Running 0 
kubernetes-bootcamp-2100875782-sbwkc Terminating 0 
kubernetes-bootcamp-390780338-9kvj j ContainerCreating 0 
kubernetes-bootcamp-390780338-hmcgb ContainerCreating 0 


图 1-18 


验证 版 本 已 经 回 退 到 v1， 如 图 1-19 所 示 。 


> curl host@1:32320 
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-hmcgb | v=1 


> curl host@1:32320 


Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-390780338-9kvjj | v=1 


> 


图 1-19 


1.7 小 结 


至 此 ， 我 们 已 经 通过 官网 的 交互 式 教 程 快速 体验 了 Kubernetes 的 功能 
和 使 用 方法 。 本 书 的 其 余 章 市 将 详细 讨论 Kubernetes 的 架构 、— 典 型 的 
部 署 方法 、 容 妖 编 排 能 力 、 网 络 方案 、 监 控 方 案 ， 帮 助 大 家 全 面 掌 握 
Kubernetes 的 核心 技能 。 


第 2 章 重要 概念 


在 实践 之 前 ， 必 须 先 学 习 Kubermetes 的 儿 个 重要 概念 ， 它 们 是 组 成 
Kubernetes 集 群 的 基石 。 


1. Cluster 


Cluster 是 计算 、 存 储 和 网 络 资源 的 集合 ，Kubernetes 利 用 这 些 资 源 运行 
各 种 基于 容 硕 的 应 用 。 


2. Master 


Master 是 Cluster 的 大 脑 ， 它 的 主要 职责 是 调度， 即 决 定 将 应 用 放 在 哪 
里 运行 。Master 运 行 Linux 操 作 系 统 ， 可 以 是 物理 机 或 者 虚拟 机 。 为 了 
实现 高 可 用 ， 可 以 运行 多 个 Master © 


3. Node 


Node 的 职责 是 运行 容器 应 用 。Node 由 Master 管 理 ，Node 负 责 监控 并 汇 
报 容 絮 的 状态 ， 同 时 根据 Master 的 要 求 管 理 容 絮 的 生命 周期 。Node 运 
行 在 Linux 操 作 系 统 上 ， 可 以 是 物理 机 或 者 是 虚拟 机 。 


在 前 面 交 互 式 教 程 中 ， 我 们 创建 的 Cluster 只 有 一 个 主机 host01， 它 既 
是 Master 也 是 Node， 如 图 2- 1 所 示 。 


Terminal + 


Kubernetes Bootcamp Terminal 
> 


> minikube start 
Starting local Kubernetes cluster... 


> kubectl get nodes 
STATUS AGE 
Ready 7s 


> hostname 
e968725c1697 


> 


图 2-1 
4. Pod 


Pod 是 Kubernetes 的 最 小 工作 单元 。 每 个 Pod 包 含 一 个 或 多 个 容器 。Pod 
中 的 容器 会 作为 一 个 整体 被 Master 调 度 到 一 个 Node 上 运行 。 


Kubernetes 引 入 Pod 主 要 基于 下 面 两 个 目的 : 

(1) 可 管理 性 。 
有 些 容 器 天 生 就 是 需要 紧密 联系 ， 一 起 工作 。Pod 提 供 了 比 容 器 更 高 
层次 的 抽象 ， 将 它们 封装 到 一 个 部 署 单元 中 。Kubernetes 以 Pod 为 最 小 
单位 进行 调度 、 扩 展 、 共 享 资源 、 管 理 生 命 周 期 。 

(2) 通信 和 资源 共享 。 
Pod 中 的 所 有 容器 使 用 同一 个 网 络 namespace， 即 相同 的 IP 地 址 和 Port 空 
间 。 它 们 可 以 直接 用 localhost 通 信 。 同 样 的 ， 这 些 容器 可 以 共 诗 存 
储 ， 当 Kubernetes 挂 载 volume 到 Pod， 本 质 上 是 将 volume 挂 载 到 Pod 中 
HI BE— TAB © 
Pods 有 两 种 使 用 方式 : 

(1) 运行 单一 容器 。 


one-container-per-Pod 是 Kubernetes 最 常见 的 模型 ， 这 种 情况 下 ， 只 是 将 
单个 容器 简单 封装 成 Pod。 即 便 是 只 有 一 个 容器 ，Kubernetes 管 理 的 也 


= Podifl Ne Bie Eas © 


问题 在 于 : WME ASE DADE — Pod 4? 
答案 是 ， 这 些 容 右 联系 必须 非常 紧密 ， 而 且 和 需要 直接 共 至 资源 。 


举 个 例子 ， 如 图 2-2 所 示 ， 这 个 Pod 包 含 两 个 容器 : 一 个 是 File Puller, 
一 个 是 Web Server ° 


File Web 
Puller Server 


图 2-2 


File Puller 会 定期 从 外 部 的 Content Manager 中 拉 取 最 新 的 文件 ， 将 其 存 
放 在 共享 的 volume 中 。Web Server 从 volume 读 取 文 件 ， 啊 应 Consumer 
的 请 求 。 


这 两 个 容器 是 紧密 协作 的 ， 它们 一 起 为 Consumer 提 供 内 最 新 的 数据 ， 同 
时 它们 也 通 过 volume 共 享 数 据 ， 所 以 放 到 一 个 Pod 是 合适 的 。 


再 来 看 一 个 反例 : 是 否 需要 将 Tomcat 和 MySQL 放 到 一 个 Pod 中 ? 


Tomcat 从 MySQL 读 取 数 据 ， 它 们 之 间 需 要 协作 ， 但 还 不 至 于 需要 放 到 
一 个 Pod 中 一 起 部 署 、 一 起 司 动 、 一 起 停止 。 同 时 它们 之 间 是 通过 
JDBC 交 换 数 据 ， 并 不 古 直接 共 至 存储 ， 所 以 放 到 各 目的 Pod 中 更 合 


JE o 


5. Controller 


Kubernetes 通 常 不 会 直接 创建 Pod， 而 是 通过 Controller 来 管理 Pod 的 。 
Controller 中 定义 了 Pod 的 部 署 特 性 ， 比 如 有 几 个 副本 、 在 什么 样 的 
Node 上 运行 等 。 为 了 满足 不 同 的 业务 场景 ，Kubernetes 提 供 了 多 种 
Controller， 包 括 Deployment ` ReplicaSet ` DaemonSet ^ StatefuleSet ^ 
Job 等 ， 我 们 逐一 讨论 。 


(1) Deployment 是 最 常用 的 Controller， 比 如 在 线 教程 中 就 是 通过 创 
建 Deployment 来 部 署 应 用 的 。Deployment 可 以 管理 Pod 的 多 个 副本 ， 并 
确保 Pod 按 照 期 望 的 状态 运行 。 


(2) ReplicaSet 实 现 了 Pod 的 多 副本 管理 。 使 用 Deployment 时 会 自动 创 
建 ReplicaSet 也 瓯 是 说 Deployment 是 通过 ReplicaSet 来 管理 Pod 的 PN 
副本 的 ， 我 们 通常 不 需要 直接 使 用 ReplicaSet 。 


(3) DaemonSet 用 于 每 个 Node 最 多 只 运行 一 个 Pod 副 本 的 场景 。 正 如 
其 名 称 所 揭示 的 ，DaemonSet 通 常用 于 运行 daemon ° 


(4) StatefuleSet 能 够 保证 Pod 的 每 个 副本 在 整个 生命 周期 中 名 称 是 不 
变 的 ， 而 其 他 Controller 不 提供 这 个 功能 。 当 某 个 Pod 发 生 故 障 需要 删 
除 并 重新 局 动 时 ，Pod 的 名 称 会 发 生变 化 ， 同 时 StatefuleSet 会 保证 副本 
按照 固定 的 顺序 启动 、 更 狐 或 者 删除 。 


(5) Job 用 于 运行 结 就 删除 的 应 用 ， 而 其 他 Controller 中 的 Pod 通 常 
是 长 期 持续 运行 。 


6. Service 


Deployment 可 以 部 署 多 个 副本 ， 每 个 Pod 都 有 目 己 的 卫 ， 外 界 如 何 访问 
这 些 副 本 呢 ? 


通过 Pod 的 IP 吗 ? 


要 知道 Pod 很 可 能 会 被 频 每 地 销 嗓 和 重 局 ， 它 们 的 卫 会 发 生变 化 ， 用 了 
来 访问 不 太 现 实 。 


A R Fe Service ° 


Kubernetes Service 定 义 了 外 界 访问 一 组 特定 Pod 的 方式 。 Service H C 
的 IP 和 端口 ，Service 为 Pod 提 供 了 负载 均衡 。 


Kubernetes 运 行 容 器 (Pod) 与 访问 容器 (Pod) 这 两 项 任务 分 别 由 
Controller 和 Service 执 行 。 


7. Namespace 


如 果 有 多 个 用 户 或 项 目 组 使 用 同一 个 Kubernetes Cluster， 如 何 将 他 们 
创建 的 Controller、Pod 等 资源 分 开 呢 ? 


TELE Namespace ° 
Namespace 可 以 将 一 个 物理 的 Cluster 光 辑 上 划分 成 多 个 虚拟 Cluster， 
个 Cluster 就 是 一 个 Namespace。 不 同 Namespace 里 的 资源 是 完全 隔离 


的 。 
Kubernetes 默 认 创建 了 两 个 Namespace， 如 图 2-3 所 示 。 


> kubectl get namespace 
NAME STATUS AGE 
default Active 17s 


kube-system Active 17s 


> 


图 2-3 
。 default: 创建 资源 时 如 果 不 指定 ， 将 被 放 到 这 个 Namespace 中 。 


e kube-system: Kubernetes 目 己 创建 的 系统 资源 将 放 到 这 个 
Namespace 中 。 


$3 ”部署 Kubernetes Cluster 


本 章 我 们 将 部 署 三 个 节点 的 Kubernetes Cluster， 如 图 3-1 所 示 。 


图 3-1 

k8s-master 是 Master，k8s-node1 和 k8s-node2 是 Node。 

所 有 市 点 的 操作 系统 均 为 Ubuntu 16.04， 当 然 其 他 Linux 也 是 可 以 的 。 
E 方 dE 装 pu 档 可 以 参 学 


https://kubernetes.io/docs/setup/independent/install-kubeadm/ ° 


注意 : Kubemetes 几 乎 所 有 的 安装 组 件 和 Docker 镜 像 都 放 在 Google 自 己 
的 网 站 上 ， 这 对 国内 的 同学 可 能 是 个 不 小 的 障碍 。 建 议 是 : 网 络 障碍 
都 必须 想 办 法 克服 ， 不 然 连 Kubemetes 的 门 都 进 不 了 。 


3.1 ”安装 Docker 


所 有 六 点 都 需要 安装 Docker。 


apt-get update && apt-get install docker.io 


3.2 ”安装 kubelet、kubeadm 和 kubectl 


在 所 有 节点 上 安装 kubelet、kubeadm 和 kubectl。 
。 kubelet 运 行 在 Cluster 所 有 六 点 上 ， 人 负责 启动 Pod 和 容器 。 
。 kubeadm 用 于 初始 化 Cluster ° 
e kubectl 是 Kubernetes 命令 行 工 具 。 通过 kubectl 可 以 部 署 和 管理 应 
用 ， 查 看 各 种 资源 ， 创 建 、 删 除 和 更 新 各 种 组 件 。 


apt-get update && apt-get install -y apt-transport-https 


curl -S https://packages.cloud.google.com/apt/doc/apt- 
key.gpg | apt-key add - 


cat ««EOF »/etc/apt/sources.list.d/kubernetes.list 
deb http://apt.kubernetes.io/ kubernetes-xenial main 
EOF 

apt-get update 


apt-get install -y kubelet kubeadm kubectl 


3.3 ”用 kubeadm 创 建 Cluster 
完 X 的 OH 方 x Bow 以 参 # 


https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/ ° 


3.3.1 ”初始 化 Master 
在 Master 上 执行 如 下 命令 : 


kubeadm init --apiserver-advertise-address 192.168.56.105 


--pod-network-cidr=10.244.0.0/16 


--apiserver-advertise-address 18 HH FA Master fH’) B ^" interface 5j Cluster fH’) EE 
他 节点 通信 。 如 果 Master 有 多 个 interface， 建 议 明确 指定 ， 如 果 不 指 
定 ，kubeadm 会 目 动 选择 有 默认 网 关 的 interface 。 


--pod-network-cidr 指 定 Pod 网 络 的 范围 。Kubernetes 文 持 多 种 网 络 方 
案 ， 而 且 不 同 网 络 方案 对 --pod-network-cidr 有 自己 的 要 求 ， 这 里 设置 
为 10.244.0.0/16 是 因为 我 们 将 使 用 flannel 网 络 方案 ， 必 须 设置 成 这 个 
CIDR。 在 后 面 的 实践 中 我 们 会 切换 到 其 他 网 络 方案 ， 比 如 Canal。 


初始 化 过 程 如 图 3-2 所 示 。 


root@k8s-master:~# kubeadm init --apiserver-advertise-address 192.168.56.105 --pod-network-cidr-10.244.0.0/16 
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters. 

[init] Using Kubernetes version: v1.7.4 

[init] Using Authorization modes: [Node RBAC] 

[preflight] Running pre-flight checks 

[preflight] Starting the kubelet service 

[kubeadm] WARNING: starting in 1.8, tokens expire after 24 hours by default (if you require a non-expiring token use --token-ttl 0) 
[certificates] Generated CA certificate and key. 

[certificates] Generated API server certificate and key. 

[certificates] API Server serving cert is signed for DNS names [k8s-master kubernetes kubernetes.default kubernetes.default.svc kubernetes .| 
96.0.1 192.168.56,105] 

[certificates] Generated API server kubelet client certificate and key. 

[certificates] Generated service account token signing key and public key. 

[certificates] Generated front-proxy CA certificate and key. 

[certificates] Generated front-proxy client certificate and key. 

[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki" 

[kubeconfig] Wrote KubeConfig file to di tc/kubernetes/admin, conf" 

[kubeconfig] Wrote KubeConfig file to di 'tc/kubernetes/kubelet.conf" 

[kubeconfig] Wrote KubeConfig file to di "/etc/kubernetes/controller-manager.conf" 

[kubeconfig] Wrote KubeConfig file to di "/etc/kubernetes/scheduler.conf" 

[apiclient] Created API client, waiting for the control plane to become ready 

[apiclient] All control plane components are healthy after 26.505992 seconds 

[token] Using token: d38001.13653e584ccc1980 

[apiconfig] Created RBAC rules 

[addons] Applied essential addon: kube-proxy 

[addons] Applied essential addon: kube-dns 


Your Kubernetes master has initialized successfully! 

To start using your cluster, you need to run (as a regular user): 
mkdir -p $HOME/.kube 
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config 
sudo chown $Cid -u):$Cid -g) $HOME/.kube/config 

You should now deploy a pod network to the cluster. 


Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at: 
http://kubernetes. io/docs/admin/addons/ 


You can now join any number of machines by running the following on each node 
las root: 


kubeadm join --token d38a01.13653e584ccc1980 192.168.56.105:6443 


root@k8s-master :~# 


图 3-2 
(1) kubeadm 执 行 初始 化 前 的 检查 。 
(2) 生成 token 和 证 书 。 
(3) 生成 KubeConfig 文 件 ，kubelet 需 要 用 这 个 文件 与 Master 通 信 。 


(4) 安装 Master 组 件 ， 会 从 Google 的 Registry 下 载 组 件 的 Docker 镜 
像 。 这 一 步 可 能 会 花 一 些 时 间 ， 主 要 取决 于 网 络 质量 。 


(5) 安装 附加 组 件 kube-proxy 和 kube-dns。 

(6) Kubernetes Master 初 始 化 成 功 。 

(7) 提示 如 何 配置 kubectl， 后 面 会 实践 。 

(8) 提示 如 何 安装 Pod 网 络 ， 后 面 会 实践 。 

(9) 提示 如 何 注册 其 他 节点 到 Cluster， 后 面 会 实践 。 


3.3.2 ”配置 kubectl 


kubectl 是 管理 Kubernetes Cluster 的 命令 行 工具 ， 前 面 我 们 已 经 在 所 有 
的 TARR 了 kubect。Master 初 始 化 完成 后 需要 做 一 些 配 置 工作 ， 然 
后 kubectl 束 能 使 用 了 。 


依照 kubeadm init 输 出 的 第 7 步 提 示 ， 推 荐 用 Linux 兽 通用 户 执行 kubectl 
(root 会 有 一 些 问题 ) ° 


我 们 为 用 户 ubuntu 配 置 kubectl: 

su - ubuntu 

mkdir -p $HOME/.kube 

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config 
sudo chown $(id -u):$(id -g) $HOME/.kube/config 

为 了 使 用 更 便捷 ， 启 用 kubectl 命 令 的 自动 补 全 功能 : 

echo "source «(kubectl completion bash)" >> -/.bashrc 


ixRÉ, ARP ubuntu n] LEH kubectl T ° 


3.3.3 ”安装 Pod 网 络 


- VEKubernetes Cluster 能 够 工作 ， 必 须 安 装 Pod 网 络 ， 否 则 Pod 之 间 无 
通信 


Kubernetes 文 持 多 种 网 络 方案 ， 这 里 我 们 先 使 用 flannel， 后 面 还 会 讨论 


Canal。 
执行 如 下 命令 部 署 flannel， 如 图 3-3 所 示 。 


kubect1 apply i 
f https://raw.githubusercontent.com/coreos/flannel/master/Docum 
entation/kube-flannel.yml 


ubuntu@k8s-master : ~$ 


ibectl apply -f https://raw.githubusercontent .com/coreos/flannel/master/Documentation/kube-flannel.yml 
ted 


daemonset "kube-flannel- 
ubuntuek8s-master :~$ 


图 3-3 


3.3.4 ”添加 k8s-nodel1 和 k8s-node2 
在 k8s-node1 和 k8s-node2 上 分 别 执行 如 下 命令 ， 将 其 注册 到 Cluster 中 : 


kubeadm join -- 
token d38a01.13653e584ccc1980 192.168.56.105:6443 


这 里 的 --token 来 和 目 前面 kubeadm init 输 出 的 第 9 步 提 示 ， 如 果 当 时 没有 
记录 下 来 ， 可 以 通过 kubeadm token list 查 看 ， 如 图 3-4 所 示 。 


* senis USAGES DESCRIPTION 
ever> authenti 


Itication,signing The default bootstrap token generated by 'kubeadm init' 


13-4 


kubeadm join 执行 如 图 3-5 所 示 。 


root@k8s-node1 :~# 
root@k8s-node1:~# kubeadm join --token d38a01.13653e584ccc1980 192.168.56.105:6443 
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters 
[preflight] Running pre-flight checks 

[preflight] Starting the kubelet service 

[discovery] Trying to connect to API Server "192.168.56.105:6443" 


Created cluster-info discovery client, 
Cluster info signature and contents are valid, will use API Server 


Successfully established connection with API Server "192.168.56.105:6443" 
Detected server version: v1.7.4 
The server supports the Certificates API (certificates.k8s.io/vibetal) 


requesting info from “https://192.168.56.105:6443" 
"https://192.168.56.105:6443" 


[csr] Created API client to obtain unique certificate for this node, generating keys and certificate signing request 
[csr] Received signed certificate from the API server, generating KubeConfig... 
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf" 


Node join complete: 
* Certificate signing request sent to master and response 


received. 


* Kubelet informed of new secure connection details. 


Run 'kubectl get nodes" 


root@k8s-nodel : ~# 


根据 提示 ， 我 们 可 以 通过 kubectl get nodes 查 看 节点 的 状态 ， 


7R o 


on the master to see this machine join. 


图 3-5 


ubuntu@k8s-master:~$ kubectl get nodes 
VERSION 


NAME 


STATUS AGE 


k8s-master NotReady 45m 
k8s-node1 NotReady 59s 
k8s-node2 NotReady 6s 


目前 所 有 市 把 都 十 NotReady， 这 是 因为 每 个 市 


图 3-6 


v1.7.4 
v1.7.4 
v1.7.4 


如 图 3-6 所 


点 都 需要 局 动 奋 干 组 


件 ， 这 些 组 件 都 是 在 Pod 中 运行 ， 需 要 首先 从 Google 下 载 镜像 。 我 们 可 
以 通过 如 下 命令 查看 Pod 的 状态 ， 如 图 3-7 所 示 。 


kubectl get pod --all-namespaces 


ubuntuék8s-master:-$ kubectl get pod --all-namespaces 


NAMESPACE 

kube-system 
kube-system 
kube-system 
kube-system 
kube-system 
kube-system 
kube-system 
kube-system 
kube-system 
kube-system 
kube-system 


NAME 


etcd- 
kube- 
kube- 
kube- 
kube- 
kube- 
kube- 
kube- 
kube- 
kube- 
kube- 


READY 
k8s-master 
apiserver-k8s-master 
controller-manager-k8s-master 
dns-2425271678-1z3pv 
flannel-ds-cqbpb 
flannel-ds-v@p3x 
flannel-ds-xk49w 
proxy-16mg9 
proxy-wc4j@ 
proxy-xL5gd 
scheduler-k8s-master 


ubuntuek8s-master: ~$ 


STATUS 

Running 

Running 

Running 

Pending 
ContainerCreating 
ImagePullBackOff 
ContainerCreating 
ContainerCreating 
Running 
ContainerCreating 
Running 


RESTARTS 


0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 


AGE 
44m 


Pending ^ ContainerCreating ` ImagePullBackOff #8 z& HH Pod? A ia , 
Running 才 是 就 绪 状 态 。 我 们 可 以 通过 kubectl describe pod «Pod Name» 
查看 Pod 的 具体 情况 ， 比 如 : 


kubectl describe pod kube-flannel-ds-vOp3x --namespace=kube- 
system 


结果 如 图 3-8 所 示 。 


图 3-8 


为 了 方 省 篇 幅 ， 这 里 只 截取 命令 输出 的 最 后 部 分 ， 可 以 看 到 在 下 载 
image 时 人 失败， 如 果 网 络 质 量 不 好 ， 这 种 情况 是 很 常见 的 。 我 们 可 以 耐 
心 等 待 ， 因 为 Kubernetes 会 重 试 ， 我 们 也 可 以 自己 手动 执行 docker pull 
去 下 载 这 个 镜像 。 


等 待 一 段 时 间 ，image 成 功 下载 后 ， 所 有 Pod 都 会 处 于 Running 状 态 ， 如 
图 3-9 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod --all-namespaces 

NAMESPACE NAME READY STATUS RESTARTS 

kube-system etcd-k&s-master 1/1 Running 
kube-apiserver-k8s-master 1/1 Running 
kube-controller-manager-k8s-master 1/1 Running 
kube-dns-2425271678-1z3pv 3/3 Running 
kube-flannel-ds-cqbpb 2/2 Running 


kube-fLannel-ds-v@p3x 2/2 Running 

kube- f Lannel-ds-xk49w 2/2 Running 

kube-proxy-16mg9 1/1 Running 

kube-proxy-wc4jQ 1/1 Running 

kube-proxy-xL5gd 1/1 Running 

kube-scheduler-k8s-master 1/1 Running 
ubuntu@k8s-master : ~$ 
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图 3-9 


这 时 ， 所 有 的 和 点 都 已 经 准备 好 了 ，Kubernetes Cluster 创 建成 功 ， 如 
图 3-10 所 示 ° 


ubuntuek8s-master : ~$ 
ubuntuek8s-master:-$ kubectl get nodes 
NAME STATUS AGE VERSION 
k8s-master Ready ih v1.7.4 


k8s-node1 Ready 18m v1.7.4 
k8s-node2 Ready 17m v1.7.4 
ubuntu@k8s-master : ~$ 


图 3-10 
3.4 小 结 


本 章 通 过 kubeadm 部 署 了 三 节点 的 Kubernetes 集 群 ， 后 面 草 世 我 们 将 在 
这 个 实验 环境 中 学 习 Kubernetes 的 各 项 技术 。 


第 4 章 ”Kubernetes 架 构 


Kubernetes Cluster 由 Master 和 Node 组 成 ， 节 点 上 运行 着 若干 Kubernetes 
服务 。 


4.1 Master Ý Ñ, 


Master = Kubernetes Cluster X lii, 3847 @ HY Daemon Jl 4 @ fh kube- 
apiserver ^ kube-scheduler ^ kube-controller-manager 、etcd 和 了 Pod 网 络 
(例如 flannel) ， 如 图 4-1 所 示 。 


API Server 
ED 
E WEEN Tg 
etcd 


4 flannel 


图 4-1 
1. API Server (kube-apiserver) 


API Server 提 供 HTTP/HTTPS RESTful API， 即 Kubernetes API ° API 
Servers Kubernetes Cluster 的 前 端 接口 ， 各 种 客户 让 m LH 〈《CLI 或 UD) 
以 及 Kubernetes 其 他 组 件 可 以 通过 它 管理 Cluster 的 各 种 资源 。 


2. Scheduler (kube-scheduler) 


Scheduler 负 责 决定 将 Pod 放 在 哪个 Node 上 运行 。Scheduler 在 调度 时 会 
当前 各 个 于 大 的 负载 ， 以 及 应 用 对 高 可 
用 、 性 能 、 数 据 杀 和 性 的 需 


3. Controller Manager (kube-controller-manager) 


Controller Manager fil 71 EE Cluster tt Pr 5 UR, PRUE BT YA TPB aK 
2 ° Controller Manager 由 多 ff controller 24 5X, , 44 replication 
controller ` endpoints controller ^ namespace controller ^ serviceaccounts 
controller 等 。 


不 同 的 controller 管 理 不 同 的 资源 。 例 如 ，replication controller 管 理 
Deployment ^ StatefulSet ^ DaemonSet 的 生命 周期 ， namespace controller 


管理 Namespace 资 源 。 


4. etcd 


etcd 负 责 保 存 Kubernetes Cluster 的 配置 信息 和 各 种 资源 的 状态 信息 。 当 
数据 发 生变 化 时 ，etcd 会 快速 地 通知 Kubernetes 相 关 组 件 。 


5. Pod 网 络 


Pod 要 能 够 相互 通信 ，Kubernetes Cluster 必 须 部 署 Pod 网 络 ，flannel 是 
其 中 一 个 可 选 方案 。 


以 上 是 Master 上 运行 的 组 件 ， 下 面 我 们 接着 讨论 Node © 
4.2 Node; 


Node 是 Pod 运 行 的 地 方 ，Kubernetes 文 持 Docker ^ rkt 7i 23 Runtime ° 
Node 上 运行 的 Kubernetes 组 件 有 kubelet、kube-proxy 和 Pod 网 络 (例如 
flannel) ， 如 图 4-2 所 示 。 


f flannel 


图 4-2 


1. kubelet 


kubelet 是 Node 的 agent， 当 Scheduler 人 确定 在 某 个 Node 上 运行 Pod 后 ， 会 
将 Pod 的 具体 配置 信息 (image ^ volumeS#) 发 送 给 该 节点 的 kubelet， 
kubelet 和 根据 这 些 信息 创建 和 运行 容 磺 ， 并 和 癌 Master 报 告 运行 状态 。 


2. kube-proxy 

service 在 逻辑 上 代表 了 后 端的 多 个 Pod， 外 界 通过 service 访 问 Pod。 
service 接 收 到 的 请 求 是 如 何 转发 到 Pod 的 呢 ? 这 了 束 是 kube-proxy 要 完成 
的 工作 。 

每 个 Node 都 会 运行 kube-proxy 服 务 ， 它 负责 将 访问 service 的 TCP/UPD 
数据 流转 发 到 后 端的 容 硕 。 如 果 有 多 个 副本 ，kube-proxy 会 实现 负载 
均衡 。 

3. Pod 网 络 


Pod 要 能 够 相互 通信 ，Kubernetes Cluster 必 须 部 署 Pod 网 络 ，flannel 是 
其 中 一 个 可 选 方案 。 


43 ”完整 的 架构 图 


结合 实验 环境 ， 我 们 得 到 了 如 图 4-3 所 示 的 染 构 图 。 


API Server 
anager 
etcd 
kube-proxy 


£$ flannel 


= oa ec» c 


flannel flannel 


4-3 
你 可 能 会 问 : 为 什么 k8s-master 上 也 有 kubelet 和 kube-proxy 呢 ? 
这 是 因为 Master 上 也 可 以 运行 应 用 ， 即 Master 同 时 也 是 一 个 Node 。 


几乎 所 有 的 Kubernetes 组 件 本 号 也 运行 在 Pod 里 ， 执 行 如 下 命令 ， 结 果 
如 图 4-4 所 示 。 


kubectl get pod --all-namespaces -0 wide 


ubuntu@k8s-master :~$ 

ubuntu@k8s-master:~$ kubectl get pod --all-namespaces -o wide 

NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE 
kube-system ^ etcd-k8s-master 1/1 Running 192.168.56.105 k&s-master 
kube-system kube-apiserver-k8s-master 121 Running 192.168.56.105 k8s-master 
kube-system kube-controller-manager-k8s-master 1/1 Running 192.168.56.105 k8s-master 
kube-system ^ kube-dns-2425271678-123pv 3/3 Running 10.244.1.57 k8s-node1 
kube-system ^ kube-flannel-ds-cabpb 2/2 Running 192.168.56.106 k8s-node1 
192.168.56.105  k8s-master 
192.168.56.107 ^ k8s-node2 
192.168.56.106 k&s-node1 
192.168.56.105 ^ k8s-master 
192.168.56.107 ^ k8s-node2 
192.168.56.105 — k8s-master 


kube-system kube-flannel-ds-v@p3x 2/2 Running 
kube-system ^ kube-flannel-ds-xk49w 2/2 Running 
kube-system kube-proxy-16mg9 1/1 Running 
kube-system ^ kube-proxy-wc4j0 1/1 Running 
kube-system kube-proxy-x15gd 1/1 Running 
kube-system kube-scheduler-k8s-master 1/1 Running 
ubuntu@k8s-master:~$ 
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图 4-4 


Kubernetes 的 系统 组 件 都 被 放 到 kube-system namespace 中 。 这 里 有 一 个 
kube-dns 组 件 ， 它 为 Cluster 提 供 DNS 服 务 ， 我 们 后 面 会 讨论 到 。kube- 
dns 是 在 执行 kubeadm init] (38527) 作为 附加 组 件 安装 的 。 


kubelet 是 唯一 没有 以 容器 形式 运行 的 Kubernetes 组 件 ， 它 在 Ubuntu 中 通 
过 Systemd 服 务 运行 ， 如 图 4-5 所 示 。 


4.4 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ sudo systemctl status kubelet.service 
e kubelet.service - kubelet: The Kubernetes Node Agent 
Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled) 
Drop-In: /etc/systemd/system/kubelet.service.d 


——10-kubeadm. conf 
Active: active (running) since Wed 2017-08-23 11:01:08 HKT; 1 day 5h ago 
http://kubernetes.io/docs/ 
: 3946 (kubelet) 
119 
: 46.4M 
: 20min 29.149s 
CGroup: /system.slice/kubelet.service 
3946 /usr/bin/kubelet --kubeconfig-/etc/kubernetes/kubelet.conf --require-kubeconfig-true 
3974 journalctl -k -f 


图 4-5 


用 例子 把 它们 串 起 来 


为 了 帮助 大 家 更 好 地 理解 Kubernetes 架 构 ， 我 们 部 署 一 个 应 用 来 演示 
各 个 组 件 之 间 是 如 何 协作 的 。 


执行 下 列 命令 ， 结 果 如 图 4-6 所 示 。 


kubectl run httpd-app --image=httpd --replicas=2 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl run httpd-app --image=httpd --replicas=2 


deployment "httpd-app" created 
ubuntu@k8s-master : ~$ 


图 4-6 


等 待 一 段 时 间 ， 应 用 部 车 完成 ， 如 图 4-7 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get deployment 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
2 2 2 2 2m 

ubuntu@k8s-master : ~$ 


ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE IP NODE 
httpd-app-3211369089-9bgrz 1/1 Running 0 2m 10.244.1.58 k8s-node1 
httpd-app-3211369089-gn6z5 1/1 Running @ 2m 10.244.2.39 k8s-node2 
ubuntu@k8s-master : ~$ 


图 4-7 


Kubernetes 部 署 了 deployment httpd-app， 有 两 个 副本 Pod， 分 别 
k8s-node1 和 Kk8s-node2 ° 


详细 讨论 整个 部 团 过 程 ， 如 图 4-8 所 示 。 


© 9 deployment 


= = g 5 
@ Q 3i 
Controller 
Em. 
etcd 


flannel 


= = ET» = 


f flannel flannel 


图 4-8 
(D kubectl 发 送 部 署 请 求 到 API Server ° 


@ API Server 通 知 Controller Manager 创 建 一 个 deployment 资 源 。 


© Scheduler 执 行 调度 任务 ， 将 两 个 副本 Pod 分 发 到 k8s-node1 和 Kk8s- 


node2 ° 
@k8s-node1 和 k8s-node2 上 的 kubectl 在 各 自 的 节点 上 创建 并 运行 Pod。 
补充 两 点 : 


(1) 应 用 的 配置 和 当前 状态 信息 保存 在 etcd 中 ， 执 行 kubect] get pod 时 
API Server 会 从 etcd 中 读 取 这 些 数据 。 


(2) flannel 会 为 每 个 Pod 都 分 配 IP。 因 为 没有 创建 service， 所 以 目前 
kube-proxy 还 没 参与 进来 。 


45 小结 


本 章 我 们 学 习 了 Kubernetes 的 架构 ， 讨 论 了 Master 和 Node 是 哪个 运行 的 
组 件 和 服务 ， 并 通过 一 个 部 署 案 例 加 深 了 对 架构 的 理解 。 


第 5 章 ”运行 应 用 


从 本 章 开 始 ， 我 们 将 通过 实践 深入 学 习 Kubernetes 的 各 种 特性 。 
容 絮 编排 引擎 ， 最 重要 也 是 最 基本 的 功能 当然 是 运行 容器 化 应 用 ， 
就 是 本 章 的 内 容 o 


5.1 Deployment 


前 面 我 们 已 经 了 解 到 ，Kubernetes 通 过 各 种 Controller 来 管理 Pod 的 生命 
周期 。 为 了 满足 不 同业 务 场 景 ，Kubernetes 开 发 了 Deployment ^ 
ReplicaSet、DaemonSet、StatefuleSet、Job 等 多 种 Controller 。 我 们 首先 
^£ 2] faci FA Deployment ° 


5.1.1 运行 Deployment 
先 从 例子 开始 ， 运 行 一 个 Deployment: 


kubectl run nginx-deployment --image=nginx:1.7.9 --replicas=2 
上 面 的 命令 将 部 署 包含 两 个 副本 的 Deployment nginx-deployment, 4s 
的 image 为 nginx:1.7.9 ° 


下 面 详细 分 析 Kubernetes 都 做 了 些 什 么 工作 ， 如 图 5-1 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl run nginx-deployment --image=nginx:1.7.9 --replicas=2 
deployment "nginx-deployment" created 

ubuntu@k8s-master : ~$ 


ubuntu@k8s-master:~$ kubectl get deployment nginx-deployment 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
nginx-deployment 2 2 2 2 23s 
ubuntu@k8s-master : ~$ 


图 5-1 


在 图 5-1 中 ， 通 过 kubect] get deployment 命 命令 查看 nginx-deployment 的 状 
态 ， 输 出 显示 两 个 副本 正常 运行 。 


接 下 来 我 们 用 kubect describe deployment 了 解 更 详细 的 信息 ， 如 图 5-2 
和 图 5-3 所 示 。 


ubuntuffiis -moster: ~$ kubectl describe deployment nginx-deployment 
; nginx-deployment 

default 
Mon, 28 Aug 2017 10:28:32 +0800 
run=nginx-dep Loyment 
deployment .kubernetes .io/revisionsi 
run=nginx-depLoyment 
2 desired | 2 updated | 2 total | 2 available | Q unavailable 
RollingUpdate 
4) 
1 max unavailable, 1 max surge 


run=nginx-depLoyment 


Containers: 
nginx-deployment: 
Image: nginx:1.7.9 
Port: «none» 
Environment: «none» 
«none» 
«none» 


Reason 


Available True MinimumReplicasAvailable 


图 5-2 


Message 


图 5-3 


大 部 分 内 容 都 是 目 解释 的 ， 我 们 重点 看 图 5-3。 这 里 告诉 我 们 创建 了 一 
个 ReplicaSet nginx-deployment-1260880958 ，Events 是 Deployment 的 日 
志 ， 记 录 了 ReplicaSet 的 启动 过 程 。 通 过 上 面 的 分 析 ， 也 验证 了 
Deployment 通 过 ReplicaSet 来 管理 Pod 的 事实 。 接 着 我 们 将 注意 力 切 换 
， 执 行 kubectl describe replicaset， 如 
5-4 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl get replicaset 


NAME DESIRED CURRENT READY AGE 
nginx-depLoyment-1260880958 2 2 2 3m 
ubuntu@k8s-master:~$ 


图 5-4 


两 个 副本 已 经 就 绪 ， 用 kubectl describe replicaset 查 看 详细 信息 ， 如 图 5- 
5 和 图 5-6 所 示 。 


ubuntu@k&s-master :~$ 
ubuntuék8s-master:-$ kubectl describe replicaset nginx-deployment-1260880958 
nginx-deployment-1260880958 
default 
pod-tempLate-hash=1260880958  run-nginx-deployment 
pod-template-hash-1260880958 
run=nginx-depLoyment 
Annotations: deployment .kubernetes.io/desired-replicas=2 
deployment .kubernetes .io/max-replicas-3 
ent .kubernetes.io/revision=1 


2 current / 2 desired 
2 Running / 0 Waiting / 0 Succeeded / 0 Failed 


Labels: pod-tempLate-hash=1260880958 
run=nginx-depLoyment 


Containers: 

nginx-deployment: 
Image: nginx:1.7.9 
Port: <none> 
Environment: <none> 
Mounts: <none> 


图 5-5 


Reason 


SuccessfulCreate Created pod: nginx- Ce -1260880958- kn8w3 
SuccessfulCreate 


图 5-6 


Controlled By 指明 此 ReplicaSet 是 由 Deployment nginx-deployment 创 建 


的 。 图 5-6 是 两 个 副本 Pod 创建 的 日 志 。 接 着 我 们 来 看 Pod， 执 行 kubectl 
get pod， 如 图 5-7 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get pod 

NAME READY STATUS RESTARTS AGE 
nginx-deployment-1260880958-kn8w3 1/1 Running 0 7m 
nginx-deployment-1260880958-rpjdc 1/1 Running 0 7m 
ubuntu@k8s-master : -$ 


图 5-7 


Poo at ume ， 然 后 用 kubectl describe pod 查 看 更 详 


细 的 信息 息 ， 如 图 5-8 和 图 5-9 所 示 。 


ubuntuek8s- master:- $ kubectl describe pod nginx-deployment-1260880958-kn8w3 
nginx-deployment-1260880958-kn8w3 
default 
k8s-node1/192.168.56.106 
Mon, 28 Aug 2017 10:28:32 «0800 
pod-template-hashs1260880958 
runenginx-deployment 
kubernetes.io/created-bys("kind":"SerializedReference" , "apiVersion":"v1", "reference" 


Running 

10.244.1.69 
ReplicaSet/nginx-deplLoyment-1260880958 
ReplicaSet/nginx-deployment-1260880958 


nginx-deployment: 
Container ID: docker ://2653d5b3aa75c16632ac2e3f c0f d5411b194d9535d47c0c50f35913334b7e0d0b 
Image: nginx:1.7.9 
Image ID: docker-pullable://nginxesha256:e3456c851a152494c3e4f f 5f cc26f240206abac0c9d794 
Port: «none» 
State: Running 
Started: Mon, 28 Aug 2017 10:28:33 +0800 
Ready: True 
Restart Count: 0 
Environment: <none> 
Mounts: 
/var/run/secrets/kubernetes, io/serviceaccount from default-token-slv6h (ro) 
Conditions: 
Type Status 
Initialized True 
Ready True 
PodScheduled True 
Volumes: 
default-token-siv6h; 
Type: Secret (a volume populated by a Secret) 
SecretName: default-token-siv6h 
Optional: false 
QoS Class: BestEffort 
Moaes selectors: <none> 


图 5-8 


Reason Message 
Scheduled Successfully assigned nginx-deployment-1260880958-kn8w3 to k 


SuccessfulMountVolume MountVolume.SetUp succeeded for volume "default-token-s1v6h" 


Pulled Container image "nginx:1.7.9" already present on machine 
Created Created container 
Started Started container 


图 5-9 
Controlled By 指明 此 Pod 是 由 ReplicaSet nginx-deployment-1260880958 创 
建 的 。Events 记 录 了 Pod 的 启动 过 程 。 如 果 操 作 失 败 (比如 image 不 存 
fe) ， 也 能 在 这 里 查 到 原因 o 


总 结 一 下 这 个 过 程 中 ， 如 图 5-10 所 示 


© nginx-deployment 
© nginx-deployment-1260880958 


图 5-10 
(1) 用 户 通 过 kubectl 创 建 Deployment ° 
(2) Deployment 创 建 ReplicaSet ° 
(3) ReplicaSet 创 建 Pod ° 


从 图 5-10 也 可 以 看 出 ， 对 象 的 命名 方式 是 “ 子 对 象 的 名 字 = 父 对 象 名 字 
+ 随机 字符 串 或 数字 ”。 


5.1.2 ”命令 vs 配置 文件 


Kubernetes 文 持 两 种 创建 资源 的 方式 : 


(1) 用 kubectl 命 令 直 接 创 建 ， 比 如 “kubect] run nginx- -deployment -- 
image=nginx:1.7.9--replicas=2”， 在 命令 行 中 通过 参数 指定 资源 的 属 


(2) 通过 配置 文件 和 kubectl apply 创 建 。 要 完成 前 面 同样 的 工作 ， 可 
执行 命令 “kubectl apply -fnginx.yml”，nginx.yml 的 内 容 如 图 5-11 所 示 。 


apiVersion: extensions/vibetal 
kind: Deployment 
metadata: 

name: nginx-deployment 


metadata: 
labels: 
app: web_server 
spec: 
containers: 


- name: nginx 
image: nginx:1.7.9 


图 5-11 
资源 的 属性 写 在 配置 文件 中 ， 文 件 格 式 为 YAML ° 
下 面 对 这 两 种 方式 进行 比较 。 

(1) 基于 命令 的 方式 : 


。 简单、 直观 、 快 捷 ， 上 和 手 快 。 
。 适合 临时 测试 或 实验 。 


(2) 基于 配置 文件 的 方式 : 
。 配置 文 件 描述 了 What， 即 应 用 最 终 要 达到 的 状态 。 


。 配置 文件 捉 供 了 创建 资产 的 模板 ， 能 够 重复 部 车。 
。 可 以 像 管理 代码 一 样 管 理 部 署 。 


。 适合 正式 的 、 跨 环境 的 、 规 模 化 部 车 。 
e 这 种 方式 要 求 熟 悉 配置 文件 的 语法 ， 有 一 定 难度 。 


后 面 我 们 都 将 采用 配置 文件 的 方式 ， 大 家 需要 尽快 熟悉 和 掌握 。 
kubectl apply 不 但 能 够 创建 Kubernetes 资 源 ， 也 能 对 资源 进行 更 新 ， 非 
各 方便。 不 过 Kubemnets 还 提供 了 几 个 类 似 的 命令 ， 例 如 kubectl 
create ` kubectl replace ` kubectl edit 和 kubectl patch ° 


ARREN ` 要 的 困扰 ， 我 们 会 尽量 只 使 用 kubectl apply， 此 命令 已 
经 能 够 应 对 百 分 之 九 十 多 的 场景 ， 事 半 功 倍 。 


5.1.3 Deployment 配 置 文件 简介 


既然 要 用 YAML 配 置 文件 部 署 应 用 ， 现 在 就 很 有 必要 了 解 
Deployment 的 配置 格式 了 ， 其 他 Controller (比如 DaemonSet) 非 
似 。 


以 nginx-deployment 为 例 ， 配 置 文件 如 图 5-12 所 示 。 


—F 


apiVersion: extensions/vibeta1 (1 
kind: Deployment (2 
metadata: (3 


name: nginx- deployment 
spec: (4 

replicas: 

template: (6 


metadata: 
Labels: 
app: web_server 
spec: (8 
containers: 
- name: nginx 
image: nginx:1.7.9 


图 5-12 

® apiVersion 是 当前 配置 格式 的 版 本 。 

© kind 是 要 创建 的 资源 类 型 ， 这 里 是 Deployment ° 

© metadata 是 该 资源 的 元 数据 ，name 是 必需 的 元 数据 项 。 


@ spec 部 分 是 该 Deployment 的 规格 说 明 。 
© replicas 指 明 副 本 数量 ， 默 认为 1。 
© template 定 义 Pod 的 模板 ， 这 是 配置 文件 的 重要 部 分 


@ metadata 定 义 Pod 的 元 数据 ， 至 少 要 定义 一 个 label。label 的 key 和 
value 可 以 任意 指定 。 


® specii Podi SU 此 部 分 定义 Pod 中 每 一 个 容 局 的 属性 ，name 和 
image 是 必需 的 。 


此 nginx.yml 是 一 个 最 简单 的 Deployment 配 置 文件 ， 后 面 我 们 学 习 
Kubernetes 各 项 功能 时 会 逐步 丰富 这 个 文件 。 


执行 kubectl apply -fnginx.yml， 如 图 5-13 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ kubectl apply -f nginx. yml 


deployment "nginx-deployment" created 
ubuntu@k8s-master: ~$ 


图 5-13 


部 署 成 功 。 同 样 ， 也 可 以 通过 kubectl get 查 看 nginx-deployment 的 各 种 
资源 ， 如 图 5-14 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get deployment 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
nginx-deployment 2 2 2 2 17s 
ubuntuék8s-master:-$ 

ubuntuek8s-master:-$ kubectl i replicaset 

NAME DESIRED ree READY AGE 
nginx-deployment-2721169382 2 2 29s 
ubuntuek8s-master :~ 

ubuntu@k8s-master:~$ kubectl get Do -o wide 

NAME READY STATUS RESTARTS AGE IP NODE 


nginx-deployment-2721169382-bl3cn 1/1 Running 0 41s 10.244.2.90  k8s-node2 
nginx-deployment-2721169382-x6f3z 1/1 Running 0 41s 10.244.1.80 k8s-nodel 
ubuntu@k8s-master : ~$ 


图 5-14 


Deployment、ReplicaSet、Pod 都 已 经 瓯 绪 。 如 果 要 删除 这 些 资源 ， 执 
行 kubectl delete deployment nginx-deployment 或 者 kubectl delete -f 


nginx.yml， 如 图 5-15 所 示 。 


ubuntu@k8s-master: ~$ 
ubuntuék8s-master:-$ kubectl delete -f nginx.yml 


deployment "nginx-deployment" deleted 
ubuntu@k8s-master: ~$ 


图 5-15 


5.1.4 伸缩 


伸缩 是 指 在 线 增加 或 减少 Pod 的 副本 数 。 


Deployment nginx-deployment 初 始 是 两 个 副本 ， 如 图 5-16 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl apply -f nginx.yml 
deployment "nginx-deployment" created 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE IP NODE 
nginx-deployment-2721169382-lgzzf 1/1 Running 0 8s 10.244.2.91  k8s-node2 
nginx-deployment-2721169382-pt53w 1/1 Running @ 8s 10.244.1.81 k8s-nodel 
ubuntu@k8s-master : ~$ 


图 5-16 


k8s-nodel 和 k8s-node2 上 各 跑 了 一 个 副本 。 现 在 修改 nginx.yml 文 件 ， 
副本 改 成 5 个 ， 如 图 5-17 所 示 。 


apiVersion: extensions/v1beta1 
kind: Deployment 
metadata: 
name: nginx-deployment 
spec: 


replicas: 


template: 


metadata 
labels: 
app: web_server 
spec: 
containers: 
- name: nginx 
image: nginx:1.7.9 


图 5-17 


再 次 执行 kubect apply， 如 图 5-18 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl apply -f nginx.yml 

deployment "nginx-deployment" configured 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE NODE 


nginx-deployment-2721169382-gbjc2 1/1 Running 0 .244.2.93 — k8s-node2 
nginx-deployment-2721169382-lgzzf 1/1 Running .244.2.91  k8s-node2 
nginx-deployment-2721169382-mbrln 1/1 Running .244.2.92  k8s-node2 
nginx-deployment-2721169382-pt53w 1/1 Running .244.1.81  k8&s-nodel 
nginx-deployment-2721169382-s6hlx 1/1 Running .244.1.82 k8s-nodel 
ubuntu@k8s-master : ~$ 


图 5-18 
三 个 新 副本 被 创建 并 调度 到 k8s-nodel 和 k8s-node2 上。 


出 于 安全 考虑 ， 默 认 配 置 下 Kubernetes 不 会 将 Pod 调 度 到 Master 节 点 。 
如 果 和 希望 将 k8s-master 也 当 作 Node 使 用 ， 可 以 执行 如 下 命令 : 


kubectl taint node k8s-master node-role.kubernetes.io/master - 
如 果 要 恢复 Master Only 状态， 执行 如 下 命令 : 


kubectl taint node k8s-master node- 
role. kubernetes.io/master="":NoSchedule 


接 下 来 修改 配置 文件 ， 将 副本 数 减 少 为 3 个 ， 重 新 执行 kubectl apply, 
如 图 5-19 所 示 。 


ubuntu@k8s-master :~$ 

ubuntu@k8s-master:~$ kubectl apply -f nginx.yml 

deployment "nginx-deployment" configured 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE NODE 
nginx-deployment-2721169382-gbjc2 1/1 Running 0 14m k8s-node2 
nginx-deployment-2721169382-lgzzf 1/1 Running 0 18m k8s-node2 
nginx-deployment-2721169382-mbrln Q/1 Terminating 0 14m k8s-node2 
nginx-deployment-2721169382-pt53w 1/1 Running 0 18m sale k8s-node1 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE IP NODE 
nginx-deployment-2721169382-gbjc2 1/1 Running 14m 10.244.2.93 | k8s-node2 
nginx-deployment-2721169382-lgzzf 1/1 Running 18m 10.244.2.91 — k8s-node2 
nginx-deployment-2721169382-pt53w 1/1 Running 18m 10.244.1.81  k8s-nodel 
ubuntu@k8s-master : ~$ 


图 5-19 


可 以 看 到 两 个 副本 被 删除 ， 最 终 保 留 了 3 个 副本 。 
5.1.5 Failover 


下 面 我 们 模拟 k8s-node2 故 了 ， 关 闭 该 节点 ， 如 图 5-20 所 示 。 


root@k&s-node2:~# halt -h 


Connection to 192.168.56.107 closed by remote host. 
Connection to 192.168.56.107 closed. 


图 5-20 


待 一 段 时 间 ，Kubernetes 会 检查 到 k8s-node2 不 可 用 ， 将 k8s-node2 上 
bb ODER 并 在 k8s-node1 上 新 创建 两 个 pod， 维 持 总 
副本 数 为 ?3， 如 图 5-21 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get node 
NAME STATUS AGE VERSION 
k8s-master Ready 6d v1.7.4 
5d v1.7.4 
v1.7.4 


ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE NODE 
nginx-deployment-2721169382-gbjc2 1/1 Unknown 0 k8s-node2 
nginx-deployment-2721169382-lgzzf 1/1 Unknown 0 

nginx-deployment-2721169382-p4mhr 1/1 Running 10. x 
nginx-deployment-2721169382-pt53w 1/1 Running 10.244.1.81 
nginx-deployment-2721169382-x8rtb 1/1 Running 10.244.1.83 
ubuntu@k8s-master : ~$ 


图 5-21 


当 k8s-node2 恢 复 后 ，Unknown 的 Pod 会 被 删除 ， 不 过 已 经 运行 的 Pod 不 
会 重新 调度 回 k8s-node2， 如 图 5-22 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get node 

NAME STATUS AGE VERSION 

k8s-master Ready 6d v1.7.4 

k8s-node1 Ready 5d v1.7.4 

k8s-node2 Ready 5d v1.7.4 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE IP 
nginx-deployment-2721169382-p4mhr 1/1 Running 1 12m 10.244.1.87 
nginx-deployment-2721169382-pt53w 1/1 Running 1 39m 10.244.1.85 
nginx-deployment-2721169382-x8rtb 1/1 Running 1 12m 10.244.1.88 
ubuntu@k8s-master: ~$ 


图 5-22 


删除 nginx-deployment， 如 图 5-23 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ kubectl delete deployment nginx-deployment 


deployment "nginx-deployment" deleted 
ubuntu@k8s-master: ~$ 


图 5-23 


5.1.6 ”用 label 控 制 Pod 的 位 置 


默认 配置 下 ，Scheduler 会 将 Pod 调 上 度 到 所 有 可 用 的 Node。 不 过 有 些 情 

况 我 们 希望 将 Pod 部 署 到 指定 的 Node， 比 如 将 有 大 量 磁盘 1/O 的 Pod 部 

do n NS 或 者 Pod 需 要 GPU， 需 要 运行 在 配置 了 GPU 
S TWA o 


Kubernetes 是 通过 label 来 实现 这 个 功能 的 。 


label 是 key-value 对 ， 各 种 资源 都 可 以 设置 label， 有 灵活 添 加 各 种 目 定 义 
属性 。 比 如 执行 如 下 命令 标注 k8s-nodel 是 配置 了 SSD 的 节点 。 


kubectl label node k8s-nodei disktype=ssd 


然后 通过 kubectl get node --show-labels 碍 看 节点 的 label ， 如 图 5-24 所 
ZN o 


master:-$ kubectl label node k8s-node1 disktype-ss 
eled 
b 


master:~$ kubectl get node --show-labels 


图 5-24 


disktype=ssd 已 经 成 功 添 加 到 k8s-node1， 除 了 disktype，Node 还 有 几 个 
Kubernetes 上 自己 维护 的 label。 


有 了 disktype 这 个 目 定义 label， 接 下 来 束 可 以 指定 将 Pod 部 署 到 k8s- 
nodel。 编 辑 nginx.yml， 如 图 5-25 所 示 。 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 
name: nginx-deployment 
spec: 
replicas: 
template: 
metadata: 
labels: 
app: web_server 
spec: 
containers 
- name: nginx 
image: nginx:1.7.9 
nodeSelector: 
disktype: 


图 5-25 


在 Pod 模 板 的 spec 里 通过 nodeSelector 指 定 将 此 Pod 部 署 到 具有 label 
disktype=ssd 的 Node 上 


部 署 Deployment 并 查看 Pod 的 运行 节点 ， 如 图 5-26 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f nginx.yml 

deployment "nginx-deployment" created 

ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE 
nginx-deployment-204403116-1kk23 1/1 Running 23s 
nginx-deployment-204403116-gcnkz 1/1 Running 23s 
nginx-deployment-204403116-kmbwr 1/1 Running 23s 
nginx-deployment-204403116-kzpnf 1/1 Running 23s 
nginx-deployment-204403116-vbz47 1/1 Running 23s 
nginx-deployment-204403116-vvh54 1/1 Running 23s 
ubuntu@k8s-master : ~$ 


图 5-26 


全 部 6 个 副 本 都 运行 在 k8s-nodel 上 ， 符 合 我 们 的 预期 。 要 删除 label 
disktype， 执 行 如 下 命令 


kubectl label node k8s-node1 disktype- 


- 即 删除 ， 如 图 5-27 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ unn label node k8s-nodel disktype- 
node "k8s-nodel" Li e 

ubuntuek8s-mast: 

ubuntu@k8s-master :~ 3 kubectl get node --show-labels 


STATUS AGE VERSION LABELS 


Ready 8d v1.7.4 beta. kubernetes. io/arch=amd64 , beta. kubernetes.io/os-linux, kubernetes . io/hostname=k8s-master ,node-role.kubernetes . io/master: 
Ready 7d v1.7.4  beta.kubernetes.io/arch-and64, beta. kubernetes. ic/os-linux, kubernetes . io/hostn: s-nodel 
Ready 7d v1.7.4 ^ beta.kubernetes.io/arch-and64, beta. kubernetes.io/os-linux, kubernetes . io/hostname-k8s-node2 

ubuntu@k8s-master :~$ 


过 此 时 Pod 并 不 会 重新 部 署 ， 依 然 在 k8s-nodel 上 运行 


B 


除非 在 nginx.yml 中 删除 nodeSelector 设 置 ， 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get pod -o wide 
NAME 

nginx-deployment-204403116-1kk23 
nginx-deployment-204403116-gcnkz 


nginx-deployment-204403116-kmbwr 
nginx-deployment-204403116-kzpnf 
nginx-deployment-204403116-vbz47 
nginx-deployment-204403116-vvh54 
ubuntu@k&s-master : ~$ 


部 署 ， 如 图 5-29 所 示 。 


ubuntu@k8s-master:~$ 


READY 


1/1 
1/1 
1/1 
1/1 
1/1 
1/1 


图 5-27 


STATUS RESTARTS AGE 
Running 0 6m 
Running 6m 
Running 6m 
Running 6m 
Running 6m 
Running 6m 


图 5-28 


ubuntu@k8s-master:~$ kubectl apply -f nginx.yml 


deployment 
ubuntu@k&8s-master : ~$ 


"nginx-deployment" configured 


ubuntu@k8s-master:~$ kubectl get pod -o wide 


NAME 
nginx-deployment-204403116-1kk23 
nginx-deployment-204403116-kmbwr 
nginx-deployment-204403116-kzpnf 
nginx-deployment-204403116-vbz47 
nginx-deployment-204403116-vvh54 
nginx-deployment-2721169382-56mhh 
nginx-deployment-2721169382-bfOrd 
nginx-deployment-2721169382-cnh8b 
nginx-deployment-2721169382-lqhn6 
nginx-deployment-2721169382-q61jr 
nginx-deployment-2721169382-r9831 
ubuntu@k8s-master: ~$ 


READY 


0/1 
1/1 
0/1 
0/1 
0/1 
1/1 
1/1 
1/1 
1/1 
1/1 
1/1 


STATUS 
Terminating 
Terminating 
Terminating 
Terminating 
Terminating 
Running 
Running 
Running 
Running 
Running 
Running 


RESTARTS AGE 


i) 


图 5-29 


IP 
<none> 


10.244.1. 


«none» 
«none» 
«none» 


Kubernetes 会 删除 之 前 的 Pod 并 调度 和 运行 新 的 Pod e 


5.2 DaemonSet 


Deployment 部 署 的 副本 Pod 会 分 布 在 各 个 Node 上 ， m 


行 好 几 个 


副本 。DaemonSet 的 不 同 之 处 在 于 : 


个 副本 


DaemonSet 的 典 


TRE 


型 应 用 场景 
(1) 在 集群 的 每 个 节 


， 如 图 5-28 所 


NODE 

k8s-node1 
k8s-node1 
k8s-node1 
k8s-node1 
k8s-node1 
k8s-node2 
k8s-node2 
k8s-node2 
k8s-node2 
k8s-node1 
k8s-node2 


每 个 Node 上 最 多 


eU 
HE 
O 86) 
只 能 


运行 存储 Daemon， 比 如 glusterd 或 ceph ° 


然后 通过 kubectl apply E jt 


iB 


运 


(2) 在 每 个 节点 上 运行 日 志 收 集 Daemon， 比 如 flunentd 或 logstash ° 


(3) 在 每 个 节点 上 运行 监控 Daemon， 比 如 Prometheus Node Exporter 
或 collectd ° 


其 实 Kubernetes 目 己 束 在 用 DaemonSet 运 行 系统 组 件 。 执 行 如 下 命令 ， 
如 图 5-30 所 示 。 


kubectl get daemonset --namespace-kube-system 


ubuntu@k&8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get daemonset --namespace=kube-system 
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE-SELECTOR 


kube-flannel-ds 3 3 3 3 3 beta. kubernetes.io/arch=ai 
kube-proxy 2 3 3 3 3 <none> 
ubuntu@k8s-master : ~$ 


图 5-30 


DaemonSet kube-flannel-ds 和 kube-proxy 分 别 负 责 在 每 个 节点 上 运行 
flannel 和 kube-proxy 组 件 ， 如 图 5-31 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get pod --namespace=kube-system -o wide 

NAME READY STATUS RESTARTS 

etcd-k8s-master 1/1 Running 192.168.56.105 — k8s-master 
kube-apiserver-k8s-master 1/1 Running 192.168.56.105 k8s-master 
kube-controller-manager-k8s-master 1/1 Running 192.168.56.105 k8&s-master 
kube-dns-2425271678-51xc4 3/3 ing 10.244.1.89 k8s-node1 
ube-flannel-ds-cqbpb Running 192.168.56.106 k8s-node1 
kube-flannel-ds-v@p3x Running 192.168.56.105 — k8s-master 
kube-flannel-ds-xk49w Running 192.168.56.107 ^ k8s-node2 
kube-proxy-16mg9 Running 192.168.56.106 k&s-node1 
kube-proxy-wc4j0 Running 192.168.56.105 k8&s-master 
kube-proxy- x15gd Running 192.168.56.107 k8s-node2 

Ss-ma: Run 8d 92-168.56.10 


D edu 
ubuntu@k8s-master : ~$ 


图 5-31 
因为 flannel 和 kube- proxy 局 于 系统 组 件 ， 需 要 在 命令 行 中 通过 -- 
指 


namespace=kube-system 指 定 namespace kube-system ° Z^ 
返回 默认 namespace default 中 的 资源 。 


5.2.1 kube-flannel-ds 


下 面 我 们 通过 分 析 kube-flannel-ds 来 学 习 DaemonSet ° 
还 记得 之 前 是 如 何 部署 flannel 网 络 的 吗 ? 我 们 执行 了 如 下 命令 


kubect1 apply i 
f https://raw.githubusercontent.com/coreos/flannel/master/Docum 
entation/kube-flannel.yml 


flannel 有 的 DaemonSet 就 定义 在 kube-flannel.yml 中 ， 如 图 5-32 所 示 。 


apiVersion: extensions/vibetal 
kind: DaemonSet (1 
metadata: 
name: kube-flannel-ds 
namespace: kube-system 
labels: 
tier: node 
app: flannel 
spec: 
template: 
metadata: 
labels: 
tier: node 


app: flannel 


spec: 

hostNetwork: 2 

nodeSelector: 
beta. kubernetes.io/arch: amd64 

containers: (3 

- name: kube-flannel 
image: quay.io/coreos/flannel:v0.8.0-amd64 
command: [ 

- name: install-cni 
image: quay.io/coreos/flannel:v0.8.0-amd64 
command: [ 


图 5-32 


注意 : 配置 文件 的 完整 内 容 要 更 复杂 一 些 ， 为 了 更 好 地 学 习 
DaemonSet， 这 里 只 保留 了 最 重要 的 内 容 。 


@ DaemonSet 配 置 文件 的 语法 和 结构 与 Deployment 儿 乎 完全 一 样 ， 只 
是 将 kind 设 为 DaemonSet ° 


Q hostName 指 定 Pod 直 接 使 用 的 是 Node 网 络 ， 相 当 于 docker run -- 
network=host。 考 虑 到 flannel 需 要 为 集群 提供 网 络 连 接 ， 这 个 要 求 是 合 
理 的 。 

© containers 定 义 了 运行 flannel 服 务 的 两 个 容器 。 


下 面 我 们 再 来 分 析 另 一 个 DaemonSet: kube-proxy ° 


5.2.2 kube-proxy 


由 于 无 法 拿 到 kube-proxy 的 YAML 文 件 ， 只 能 运行 如 下 命令 查看 配置 : 
kubectl edit daemonset kube-proxy --namespace-kube-system 
结果 如 图 5-33 所 示 。 


apiVersion: extensions/vibetai 
kind: DaemonSet (1 
metadata: 
labels: 
k8s-app: kube-proxy 
name: kube-proxy 
namespace: kube-system 
spec: 
selector: 
matchLabels: 
k8s-app: kube-proxy 
template: 
metadata: 
labels: 
k8s-app: kube-proxy 
spec: 
containers: 
- command: 
- /usr/local/bin/kube-proxy 
- --kubeconfig=/var/1ib/kube-proxy/kubeconfig. conf 
- --cluster-cidr-10.244.0.0/16 
image: gcr.io/google containers/kube-proxy-amd64:v1.7.4 
name: kube-proxy 
status: (3 
currentNumberScheduled: 
desiredNumberScheduled: 
numberAvailable: 
numberMisscheduled: 
numberReady : 
observedGeneration: 
updatedNumberSchedulLed: 


图 5-33 
同样 为 了 便于 理解 ， 这 里 只 保留 了 最 重要 的 信息 。 
(D kind: DaemonSet 指 定 这 是 一 个 DaemonSet 类 型 的 资源 。 
© containers 定 义 了 kube-proxy 的 容器 。 


© status 是 当前 DaemonSet 的 运行 行 时 状态 ， 这 个 部 分 是 kubect edit 特 有 
的 。 其 实 Kubernetes 集 群 中 每 个 当前 运行 的 资源 都 可 以 通过 kubectl edit 


查看 其 配置 和 运行 状态 ， 比 如 kubectl edit deployment nginx- 
deployment ° 


5.2.3 “运行 目 己 的 DaemonSet 


AX /|\ Ti LA Prometheus Node Exporter 7j £7] 18 zrs Hd FP? an fi 3s fT El CR 


DaemonSet ° 


Prometheus 是 流行 的 系统 监控 方案 ，Node Exporter 7 Prometheus 的 
agent， 以 Daemon 的 形式 运 4 了 在 签 个 被 监控 节点 下 o 
Ay 人、 


如 果 是 直接 在 Docker 中 运行 Node Exporter Zii, MNH: 


docker run -d \ 
-v "/proc:/host/proc" \ 
-v "/sys:/host/sys" \ 
-v "/:/rootfs" \ 
--net=host \ 
prom/node-exporter \ 
--path.procfs /host/proc \ 
--path.sysfs /host/sys \ 


--collector. filesystem. ignored-mount - 
points "^/(sys|proc|dev|host|etc)($]|/)" 


将 其 转换 为 DaemonSet 的 YAML 配 置 文件 node_exporter.yml， 如 图 5-34 
所 示 。 


lapiVersion: extensions/vibetal 
kind: DaemonSet 
metadata: 
name: node-exporter-daemonset 
spec: 
template: 
metadata: 
labels: 
app: prometheus 
spec: 
hostNetwork: 
containers: 
- name: node-exporter 
image: prom/node-exporter 
imager BETEoticys IfNotPresent 
command: 
/bin/node_exporter 
--path.procfs 
/host/proc 
--path.sysfs 
/host/sys 
- --collector.filesystem.ignored-mount-points 
- ^/CsysIprocidevIhostletc)C$1/) 
volumeMounts: 
- name: proc 
mountPath: /host/proc 
name: Sys 
mountPath: /host/sys 
- name: root 
mountPath: /rootfs 
volumes: 
- name: proc 
hostPath: 
path: /proc 
- name: sys 
hostPath: 
path: /sys 
- name: root 
hostPath: 
path: / 


图 5-34 
© 直接 使 用 Host 的 网 络 。 
Q ix Aa Aaa 


© 通过 Volume 将 Host 路 径 /proc、/sys 和 / 枫 射 到 容器 中 。 我 们 将 在 后 面 
详细 讨论 Volume 。 


执行 kubectl apply -f node_exporter.yml， 如 图 5-35 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl apply -f node. exporter.yml 
daemonset "node-exporter-daemonset" created 
ubuntu@k8s-master : ~$ 


ubuntu@k8s-master:~$ kubectl get dw -0 wide 

NAME ADY STATUS RESTARTS AGE IP NODE 
node-exporter-daemonset-b2w@x wa Running 0 6s 192.168.56.107 . k8s-node2 
node-exporter-daemonset-kvmkr 1/1 Running 0 6s 192.168.56.106 ^ k8s-node1 
ubuntu@k8s-master : ~$ 


图 5-35 


DaemonSet node-exporter-daemonset 部 署 成 功 ，k8s-node1 和 k8s-node2 上 
分 别 运 行 了 一 个 node exporter Pod 。 


5.3 Job 


容 贺 按照 持续 运行 的 时 间 可 分 为 两 类 : 服务 类 容器 和 工作 类 容器 。 

RARA: 右 通 党 持续 提供 服务 ， 需 要 一 直 运 行 ， 比 如 HTTP Server ` 
s f 类 容器 则 是 一 次 性 任务 ， 比如 批 处 理 程序 ， 完 成 后 容 
jj 


Kubernetes 的 Deployment、ReplicaSet 和 DaemonSet 都 用 于 管理 服务 类 容 
at; 对 于 工作 类 容 右 ， 我 们 使 用 Job。 


先 看 一 个 简单 的 Job 配 置 文件 myjob.yml， 如 图 5-36 所 示 。 


BE 
ME 
“te 


apiVersion:.  batch/v1 | 1 


name: myjob 
spec: 
template: 
metadata: 

name: myjob 

spec: 

containers: 

- name: hello 
image: busybox 
command: [ 

restartPolicy: Never (3 


图 5-36 


(D batch/v1 是 当前 Job 的 apiVersion ° 


© 指明 当前 资源 的 类 型 为 Job。 
© restartPolicy 指 定 什 么 情况 下 需要 重启 容器 。 对 于 Job， 


Never 或 者 OnFailure。 对 于 其 他 controller (比如 Deployment) 


‘J Always ° 


通过 kubectl apply -fmyjob.yml 启 动 Job， 如 图 5-37 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ kubectl apply -f myjob.yml 


job "myjob" created 
ubuntu@k8s-master : ~$ 


图 5-37 


通过 kubectl get job 查看 Job 的 状态 ， 如 图 5-38 所 示 。 


ubontuéldis- master: -$ kubectl get job 
NAME DESIRED SUCCESSFUL AGE 
myjob 1 1 12s 
ubuntu@k8s-master : ~$ 


图 5-38 


ee E 表示 按照 预期 启动 了 一 个 Pod， 并 且 
经 成 功 执行 。 通 过 kubectl get pod 查 看 Pod 的 状态 ， 如 图 5-39 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get pod 

No resources found, use --show-all to see completed objects. 
ubuntu@k8s-master:~$ 


ubuntu@k8s-master:~$ kubectl get pod --show-all 
NAME READY STATUS RESTARTS 
myjob-nfkxk Q/1 Completed 0 
ubuntu@k8s-master:~$ 


图 5-39 


因为 Pod 执 行 完 毕 后 容器 已 经 退出 ， 需 要 用 --show-all 才 能 查看 


Completed RS 的 Pod。 


通过 kubectl logs 可 以 查看 Pod 的 标准 输出 ， 如 图 5-40 所 示 。 


ubuntuék8s master : ~$ 
ubuntuék8s-master:-$ kubectl logs myjob-nfkxk 


hello k8s job! 
ubuntu@k8s-master : ~$ 


图 5-40 


5.3.1 Pod 失 败 的 情况 


以 上 是 Pod 成 功 执行 的 情况 ， 如 有 果 Pod 失 败 了 会 怎么 样 呢 ? 
我 们 做 个 试验 ， 修 改 myjob.yml， 改 意 引 入 一 个 错误 ， 如 图 5-41 所 示 。 


apiVersion: batch/v1 
kind: Job 
metadata: 
name: myjob 
spec: 
template: 
metadata: 
name: myjob 
spec: 
containers: 


图 5-41 


先 删 除 之 前 的 Job， 如 图 5-42 所 示 。 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ kubectl delete -f myjob.yml 
job "myjob" deleted 
ubuntu@k8s-master: ~$ 


图 5-42 


运行 新 的 Job 并 得 看 状态 ， 如 图 5-43 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ kubectl apply -f myjob.yml 
job "myjob" created 
ubuntuék8s -master : ~$ 


ubuntuék8s-master:-$ kubectl get job 
NAME DESIRED SUCCESSFUL AGE 
myjob 1 0 7s 
ubuntuek8s-master : ~$ 


图 5-43 


当前 SUCCESSFUL 的 Pod 数 量 为 0， 查 看 Pod 的 状态 ， 如 图 5-44 所 示 。 


UD 
ub p 
NAME EA STATUS RESTARTS 
my job-0x0z0 ContainerCannotRun 


ContainerCannotRun 
ContainerCannotRun 
ContainerCannotRun 
ContainerCannotRun 
ContainerCreating 


ubuntuék8s-master : ~$ 
图 5-44 


可 以 看 到 有 多 个 Pod， 状 态 均 不 正常 。 通 过 kubectl describe pod 碍 看 某 
个 Pod 的 局 动 日 志 ， 如 图 5-45 所 示 。 


assigned myjob-O0x0z0 to k8s-node2 
succeeded for volume "default-token-k87vh" 


图 5-45 


日 志 显 示 没 有 可 执行 程序 ， 符 合 我 们 的 预期 。 


下 面 解释 一 个 现象 : 为 什么 kubectl get pod 会 看 到 这 么 多 个 失败 的 
Pod? 


RAG: 当 第 一 个 Pod 启 动 时 ， 容 器 失败 退出 ， 根 据 restartPolicy: 
Never， 此 失败 容器 不 会 被 重启 ， 但 Job DESIRED 的 Pod 是 1， 目 前 
SUCCESSFUL 为 0， 不 满足 ， 所 以 Job controller 会 局 动 新 的 Pod， 直 到 
SUCCESSFUL 为 1° 对 于 我 们 这 个 例子 ，SUCCESSFUL 永 远 也 到 不 了 
1， 所 以 Job controller 会 一 直 创 建新 的 Pod。 为 了 终止 这 个 行为 ， 只 能 
删除 Job， 如 图 5-46 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl delete -f myjob.yml 


job "myjob" deleted 
ubuntu@k8s-master: ~$ 


图 5-46 


如 果 将 restartPolicy 设 置 为 OnFailure 会 怎么 样 ? 下 面 我 们 实践 一 下 ， 修 
改 myjob.yml 后 重新 启动 ， 如 图 5-47 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f myjob.yml 
job "myjob" created 

ubuntu@k8s-master : ~$ 


ubuntu@k8s-master:~$ kubectl get job 
NAME DESIRED SUCCESSFUL AGE 
myjob al 0 5s 

ubuntu@k8s-master : ~$ 


图 5-47 


Job 的 SUCCESSFUL Pod 数 量 还 是 0， 再 看 看 Pod 的 情况 ， 如 图 5-48 所 
ZN o 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get pod --show-all 


NAME READY STATUS RESTARTS AGE 
myjob-831x0 0/1 CrashLoopBackOff {3 1m 


ubuntu@k8s-master : ~$ 


图 5-48 


这 里 只 有 一 个 Pod， 不 过 RESTARTS 为 3， 而 且 不 断 增 加 ， 说 明 
OnFailure 生 效 ， 容 器 失败 后 会 自动 重启 。 


5.3.2 ”Job 的 并 行 性 


有 时 我 们 希望 能 同时 运行 多 个 pod， 提 高 Job 的 执行 效率 。 这 个 可 以 通 
过 parallelism 设 置 ， 如 图 5-49 所 示 。 


apiVersion: batch/v1 


name: myjob 


spec: 
parallelism: 
template: 


metadata: 
name: myjob 
spec: 
containers: 
- name: hello 
image: busybox 
command: [ 


restartPolicy: OnFailure 


图 5-49 


这 里 我 们 将 并 行 的 Pod 数 量 设置 为 2， 实 践 一 下 ， 如 图 5-50 所 示 。Job 一 


共 启 动 了 两 个 Pod， 而 且 AGE 相 同 ， 


我 们 还 可 以 通 


不 。 


Ay We 


ubuntuék8s -master : ~$ 
ubuntu@k8s-master:~$ kubectl apply -f myjob.yml 
job "myjob" created 

ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get job 

NAME DESIRED 


SUCCESSFUL AGE 
myjob <none> 2 6s 
ubuntu@k8s-master : ~$ 


并 行 运 行 的 。 


ubuntu@k8s-master:~$ kubectl get pod --show-all -o wide 


NAME READY 
myjob-cn4zs 0/1 
myjob-vhpzs 0/1 
ubuntu@k8s-master:~$ 


STATUS RESTARTS AGE 
Completed 0 12s 
Completed 0 12s 


图 5-50 


apiVersion: batch/v1 
kind: Job 
metadata: 
name: myjob 
spec: 
completions: 


template: 


metadata: 
name: myjob 

spec: 
containers: 


- name: hello 
image: busybox 
command: [ 3 
restartPolicy: OnFailure 


图 5-51 


IP NODE 
10.244.2.5 k8s-node2 
10.244.1.28 k8s-node1 


前 过 completions 设 置 Job 成 功 完成 Pod 的 总 数 ， 如 图 5-51 所 


上 面 配置 的 含义 是 : 每 次 运行 两 个 Pod， 直 到 总 共有 6 个 Pod 成 功 完 
成 。 实 践 一 下 ， 如 图 5-52 所 示 。 


ubuntu@k&8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl apply -f myjob.yml 
job "myjob" created 
ubuntu@k8s-master :~ 


ubuntu@k8s-master:~$ kubectl get job 
NAME DESIRED SUCCESSFUL AGE 
myjob 6 6 9s 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ 


ubuntu@k8s-master:~$ kubectl get pod --show-all -o wide 

NAME READY STATUS RESTARTS AGE IP NODE 

myjob-Ot4zk X 0/1 Completed 0 16s 10.244.2.6 k8s-node2 
0/1 Completed 11s 10.244.2.8 k8s-node2 
0/1 Completed 14s 10.244.1.30  k8s-node1 
0/1 Completed 13s 10.244.2.7 k8s-node2 
0/1 Completed 12s 10.244.1.31  k8s-node1 
0/1 Completed 16s 10.244.1.29  k8s-node1 

ubuntu@k8s-master: ~$ 


图 5-52 


DESIRED 和 SUCCESSFUL 均 为 6， 符 合 预 期 。 如 有 果 不 指定 completions 
和 parallelism， 默 认 值 均 为 1。 


上 面 的 例子 只 是 为 了 演示 Job 的 并 行 特性 ， 实 际 用 途 不 大 。 不 过 现实 中 
确实 存在 很 多 需要 并 行 处 理 的 场景 。 比 如 批 处 理 程序 ， 每 个 副本 

(Pod) 都 会 从 任务 池 中 读 取 任务 并 执行 ， 副 本 越 多 ， 执 行 时 间 就 越 
短 ， 效 率 束 越 高 。 这 种 类 似 的 场景 都 可 以 用 Job 来 实现 。 


5.3.3 SER Job 


Linux 中 有 cron 程 序 定时 执行 任务 ，Kubernetes 的 CronJob 提 供 了 类 似 的 
功能 ， 可 以 定时 执行 Job。CronJob 配 置 文件 示例 如 图 5-53 所 示 。 


apiVersion: batch/v2alpha1 (- 
kind: CronJob (2 
metadata: 

name: hello 
spec: 

schedule: 

jobTemplate: (4 

spec: 


template: 
spec: 
containers: 
- name: hello 
image: busybox 
command: [ 3 
restartPolicy: OnFailure 


图 5-53 


® batch/v2alphal 是 当前 CronJob 的 apiVersion ° 
© 指明 当前 资源 的 类 型 为 CronJob。 


© schedule 指 定 什 么 时 候 运 行 Job， 其 格式 与 Linux cron 一 致 。 这 里 */1 * 
* 的 舍 义 是 每 一 分 钟 启动 一 次 。 


@ jobTemplate 定 义 Job 的 模板 ， 格 式 与 前 面 的 Job 一 致 。 
接 下 来 通过 kubectl apply 创 建 CronJob， 如 图 5-54 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl apply -f cronjob.yml 


error: error validating "cronjob.yml": error validating data: the server could not find th 
resource; if you choose to ignore these errors, turn validation off with --validate-false 
ubuntu@k8s-master : ~$ 


图 5-54 


失败 了 。 这 是 因为 Kubernetes 默 认 没有 enable CronJob 功 能 ， 需 要 在 
kube-apiserver 中 加 入 这 个 功能 。 方 法 很 简单 ， 修 改 kube-apiserver 的 配 
置 文 件 /etc/kubernetes/manifests/kubeapiserver.yaml， 如 图 5-55 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 
annotations: 
scheduler.alpha.kubernetes.io/critical-pod: 
creationTimestamp: 
labels: 
component: kube-apiserver 
tier: control-plane 
name: kube-apiserver 
namespace: kube-system 
spec: 
containers: 
- command: 


--runtime-config 

--requestheader-group-headers-X-Remote-Group 
--requestheader-extra-headers-prefix=X-Remote-Extra- 
--requestheader-allowed-names=front-proxy-cLlient 
--kubelet-client-key-/etc/kubernetes/pki/apiserver-kubelet-clieni 
--kubelet-preferred-address-types-InternalIP,ExternalIP,Hostname 
--allow-privileged- 

--experimental-bootstrap-token-auth- 
--requestheader-username-headers=X-Remote-User 
--service-account-key-file=/etc/kubernetes/pki/sa. pub 


图 5-55 


kube-apiserver 本 喘 也 是 一 个 Pod ， 在 启动 参数 中 加 上 --runtime- 
config=batch/v2alphal= traeBlT8] 然后 重启 kubelet 服 务 : 


systemctl restart kubelet.service 


kubelet & Œ JA kube-apiserver Pod ° 38i X} kubectl api-versions fff 14 kube- 
apiserver 现 在 已 经 支持 batch/v2alphal1， 如 图 5-56 所 示 。 


ubuntu@k8s-master: -$ kubectl api-versions 
apiextensions.k8s.io/vibetal 
apiregistration.k8s.i0o/vibetal 
apps/vibetal 

authentication. k8&s.i0/v1 
authentication.k8&s.io/vibetal 
authorization. k8&s.io/v1 
authorization. k8s.io/vibetal 
autoscaling/v1 

batch/v1 
certificates.k8s.10/vibetal 
extensions/vibetal 

networking. k8&s.10/v1 
policy/vibetal 
rbac.authorization.k8s.io/vialphai 
rbac.authorization.k8s.i10/vibetal 
settings.k8s.io/vialphai 
storage.k8s.io/v1 
storage.k8&s.i0/vibetal 

v1 

ubuntuék8s-master : ~$ 


图 5-56 


再 次 创建 CronJob， 如 图 5-57 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl apply -f cronjob.yml 


cronjob "hello" created 
ubuntu@k8s-master : ~$ 


图 5-57 


这 次 成 功 了 。 通 过 kubectl get cronjob 查 看 CronJob 的 状态 ， 如 图 5-58 所 


zl bd 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ kubectl get cronjob 
NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE 


hello s Iottoe t False 0 Tue, 12 Sep 2017 10:21:00 +0800 
ubuntu@k8s-master : ~$ 


图 5-58 


等 待 儿 分 钟 ， 然 后 通过 kubectl get jobs 查 看 Job 的 执行 情况 ， 如 图 5-59 
所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl get jobs 
NAME DESIRED SUCCESSFUL AGE 
hello-1505181600 1 1 5m 
hello-1505181660 i 4m 
hello-1505181720 il 3m 
hello-1505181780 1 2m 
hello-1505181840 1 1m 
hello-1505181900 1 3s 
ubuntu@k8s-master: ~$ 


图 5-59 


M E 5J]— ^ Job ° 3A fT kubectl logs 可 查看 某 个 
Job 的 运行 日 志 ， 如 图 5-60 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get pod --show-all 

NAME READY STATUS RESTARTS AGE 
hello-1505181600-@hrx5 0/1 Completed 0 5m 
hello-1505181660-nbgwd Q/1 Completed 4m 
hello-1505181720-1f350 0/1 Completed 3m 
hello-1505181780-tjhq2 0/1 Completed 2m 


hello-1505181840-lqdbv 0/1 Completed im 
hello-1505181900-ggfr2 Q/1 Completed 10s 
ubuntuék8s master : ~$ 

ubuntuék8s-master:-$ kubectl logs hello-1505181720-1f350 
hello k8s job! 

ubuntuék8s master : ~$ 


图 5-60 


5.4 ”小结 


BI pu ocu 。 为 满足 不 同 的 业务 
m Z, Kubernetes 提供 了 多 种 Controller ， 包 括 Deployment ^ 
ean * Job ^ dau. 本 章 我 们 通过 实践 详细 学 习 了 这 些 
Controller， 并 讨论 了 它们 的 特性 和 应 用 场景 。 


第 6 间 通过 Service 访 问 Pod 


我 们 不 应 该 期 望 Kubernetes Pod 是 健壮 的 ， 而 是 要 假设 Pod 中 的 容 需 很 
可 能 因为 各 种 原因 发 生 故 障 而 死 掉 。Deployment 等 Controller 会 通过 动 
态 创建 和 销毁 Pod 来 保证 应 用 整体 的 健壮 性 。 换 句 话 说，Pod 是 脆弱 
的 ， 但 应 用 是 健壮 的 。 


每 个 Pod 都 有 自己 的 IP 地 址 。 当 Controller 用 新 Pod 替 代 发 生 故 障 的 Pod 
时 ， 新 Pod 会 分 配 到 新 的 IP 地 址 。 这 样 就 产生 了 一 个 问题 : 


如 果 一 组 Pod 对 外 提供 服务 (比如 HTTP) ， 它 们 的 IP 很 有 可 能 发 生变 
化 ， 那 么 客户 端 如 何 找到 并 访问 这 个 服务 呢 ? 


Kubemetes 给 出 的 解决 方案 是 Service。 


6.1 创建 Service 


Kubernetes Service 从 逻辑 上 代表 了 一 组 Pod， 具 体 是 哪些 Pod 则 是 由 
label 来 挑选 的 。Service 有 自己 的 IP， 而 且 这 个 IP 是 不 变 的 。 客 户 端 只 
需要 访问 Service 的 IP，Kubemetes 则 负责 建立 和 维护 Service 与 Pod 的 映 
射 和 关系 。 无 论 后 端 Pod 如 何 变 化 ， 对 客户 端 不 会 有 任何 影响 ， 因 为 


Service 没 有 变 。 


来 看 个 例子 ， 创 建 下 面 的 这 个 Deployment， 如 图 6-1 所 示 。 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 

name: httpd 
spec: 

replicas: 

template: 

metadata: 

labels: 
run: httpd 

spec: 

containers: 

- name: httpd 
image: httpd 
ports: 

- containerPort: 


图 6-1 


我 们 启动 了 三 个 Pod， 运 行 httpd 镜 像 ，label 是 run: httpd，Service 将 会 
这 个 label 来 挑选 Pod， 如 图 6-2 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f httpd.yml 

deployment "httpd" created 

ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE NODE 
httpd-741508562-192vp 1/1 Running 0 1m .4. k8s-node1 
httpd-741508562-6g4fc 1/1 Running 0 1m .4. k8s-node1 
httpd-741508562-6hh9g 1/1 Running 0 1m ` 15: k8s-node2 
ubuntu@k8s-master:~$ 


图 6-2 


Pod 分 配 了 省 目的 IP， 这 些 JP 只 能 被 Kubernetes Cluster 中 的 容器 和 市 所 
访问 ， 如 图 6-3 所 示 。 
ubuntu@k8s-master:~$ 


ubuntu@k8s-master:~$ curl 10.244.4.5 
<html><body><h1>It works!«/h1»«/body»«/html» 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ curl 10.244.5.4 
<html><body><h1>It works!</h1></body></html> 
ubuntu@k8s-master:~$ 


图 6-3 


返 下 来 创建 Service， 其 配置 文件 如 图 6-4 所 示 。 


apiVersion: v1 (1) 
kind: Service a 
metadata: 


fr) 


name: httpd-svc (3 
spec: 


selector: 
run: httpd (4 
ports: 
- protocol: TCP 5 
port: 
targetPort: 


图 6-4 
(D v1 是 Service 的 apiVersion ° 
@ 指明 当前 资源 的 类 型 为 Service。 
© Service 的 名 字 为 httpd-svc ° 
@ selector 指 明 挑选 那些 label 为 run: httpd 的 Pod 作 为 Service 的 后 端 。 
© 将 Service 的 8080 端 口 映 射 到 Pod 的 80 端 口 ， 使 用 TCP 协 议 。 
执行 kubectl apply 创 建 Service httpd-svc， 如 图 6-5 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl apply -f httpd-svc.yml 
service "httpd-svc" created 

ubuntu@k8s-master : ~$ 


ubuntu@k8s-master:~$ kubectl get service 

NAME CLUSTER-IP EXTERNAL-IP X PORT(S) 

httpd-svc 10.99.229.179 . «none» 8080/TCP 
kubernetes 10.96.0.1 <none> 443/TCP 

ubuntu@k8s-master : ~$ 


图 6-5 


httpd-svc 分 配 到 一 个 CLUSTER-IP 10.99.229.179。 可 以 通过 该 IP 访 问 后 
"mHJhttpd Pod， 如 图 6-6 所 示 。 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ curl 10.99.229.179:8080 


<html><body><hi>It works! </h1></body></htm1> 
ubuntu@k8s-master : ~$ 


图 6-6 
根据 前 面 的 端口 映射 ， 这 里 要 使 用 8080 端 口 。 另 外 ， ones ae 
httpd-svc， 还 有 一 个 Service kubernetes，Cluster 内 部 通过 这 个 Service 访 


问 Kubernetes API s o 


通过 kubectl describe 可 以 查看 httpd-svc 与 Pod 的 对 应 关系 ， 如 图 6-7 所 
ZN o 


ubuntu@k8s-master: ~$ 
ubuntu@k&8s-master:~$ kubectl describe service httpd-svc 
Name: httpd-svc 
Namespace: default 
Labels: <none> 
Annotations: kubectl.kubernetes.io/last-applied-configuration 
:8080,"protocol":"TC... 
Selector: run-httpd 
ClusterIP 
10.99.229.179 
<unset> 8080/TCP 
10.244.4.4:80 


TTT Te RUST 
Events: 
ubuntu@k8s-master : ~$ 


图 6-7 
Endpoints 罗 列 了 三 个 Pod 的 IP 和 端口 。 我 们 知道 Pod 的 IP 是 在 容器 中 配 
置 的 ， 那 么 Service 的 Cluster 症 又 是 配置 在 哪里 的 呢 ? CLUSTER-IP X. 
是 如 何 映射 到 Pod IPRJUE? 


答案 是 iptables。 


6.2 Cluster IP 底 层 实现 


Cluster IP 是 一 个 虚拟 IP， 是 由 Kubernetes 节 点 上 的 iptables 规 则 管理 
的 。 


可 以 通过 iptables-save 命 令 打 印 出 当前 万 点 的 iptables 规 则 ， 因 为 输出 较 
多 ， 这 里 只 截取 与 httpd-svc Cluster IP 10.99.229.179 相 关 的 信息 ， 如 图 
6-8 所 示 。 


-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.99.229.179/32 -p tcp -m comment -comment “default/httpd-svc: 
Cluster IP” -m tcp -dport 8080 —j KUBE-MARK-MASQ 


-A KUBE-SERVICES -d 10.99.229.179/32 -p tcp -m comment -comment *default/httpd-svc: Cluster IP" -m tcp 
-dport 8080 —j KUBE-SVC-RL3JAE4GN7VOGDGP 


图 6-8 
这 两 条 规则 的 含义 是 : 


(1) 如 果 Cluster 内 的 Pod ( 源 地 址 来 自 10.244.0.0/16) 要 访问 httpd- 
svc， 则 允许。 


(2) 其 他 源 地 址 访问 httpd-svc， 跳 转 到 规则 KUBE-SVC- 
RL3JAE4GN7VOG DGP ° KUBE-SVC-RL3JAE4GN7VOGDGP 规 则 如 
图 6-9 所 示 。 


-A KUBE - SVC-RL3JAE4GN7VOGDGP -m comment - 
comment  "default/httpd-svc: " -m statistic -mode random - 
probability 0.33332999982 -j KUBE-SEP-C5KB52P4BBJQ35PH 

-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment *default/httpd-svc: " -m statistic -mode random -prob 


ability 0.33332999982 -j KUBE-SEP-C5KB52P4BBJQ35PH 
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment *default/httpd-svc: " -m statistic -mode random -prob 


ability 0.50000000000 -j KUBE-SEP-HGVKQQZZCF7RV41T 
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment *default/httpd-svc: " -j KUBE-SEP-XE25WGVXLHEIRVO5 


图 6-9 
(1) 13 的 概率 跳 转 到 规则 KUBE-SEP-C5KB52P4BBJQ35PH ° 


(2) 13 的 概率 〈 剩 下 23 的 一 半 ) 跳 转 到 规则 KUBE-SEP- 
HGVKQQZZCF7RVA4IT ° 


(3) 1/3 的 概率 跳 转 到 规则 KUBE-SEP-XE25WGVXLHEIRVO5。 
上 面 三 个 跳 转 的 规则 如 图 6-10 所 示 。 


-A KUBE-SEP-C5KB52P4BBJQ35PH - Eun i 4. Nites "defa DAC " -j KUBE-MARK-MASQ 
-A KUBE-SEP-CSKB52P4BBJQ35PH -p t comment --com icu "defa ult/nttpd- svc:" -m ee DNAT --to-destination 10.244.4.4:80 
-A KUBE-SEP-HGVKQQZZCF7RV41T -s ni Z5. 4, eum m comment mment "defa ult/ht ves 5 


-A KUBE-SEP-HGVKQQZZCF7RV4IT -p tcp -m comment --comment “defy dm svc:" -m n -j -to- sti n 10.244.4.5:80 
-A KUBE-SEP-XE25WGVXLHEIRVOS -s 10.244.5.4/32 -m comment - lent "defa uLt/httpd- svc:" -j KUBE- MARK- NASQ 
-A KUBE-SEP-XEZSWGVXLHEIRVOS -p tcp -m comment --comment AT svc:" -m tcp p DNAT --to-destination 10.244.5.4:80 


图 6-10 


即将 请 求 分别 转 发 到 后 端的 三 个 Pod 。 通过 上 面 的 分 析 ， 我 们 得 到 结 
论 : iptables 将 访问 Service 的 流量 转发 到 后 端 Pod， 而 且 使 用 类 似 轮 询 
的 负载 均衡 策略 。 


为 hy T 需要 补充 一 点 Cluster 的 每 一 个 人 后 都 配置 了 相同 的 iptables 规 
则 ， 这 样 就 确保 了 个 Cluster 都 能 够 通过 Service 的 Cluster IP 访 问 
Service， 如 图 6-11 所 示 。 


Cluster IP 
(iptables) 
10.99.229.179 10.99.229.179 
Cluster IP Cluster IP 
(iptables) (iptables) 
ee httpd-741508562-6hh9g 
2444. (9) 1024454 


AMD httpd-741508562-6g4fc 
[9) 1024444 


图 6-11 


6.3 DNS 访问 Service 


在 Cluster 中 ， 除 了 可 以 通过 Cluster IP 访 问 Service，Kubernetes 还 提供 了 
更 为 方便 的 DNS 访问 。 


kubeadm 部 署 时 会 默认 安装 kube-dns 组 件 ， 如 图 6-12 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ kubectl get deployment --namespace=kube-system 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
kube-dns T T 1 1 5d 
ubuntu@k8s-master: ~$ 


图 6-12 


kube-dns 是 一 个 DNS 服务 器 。 每 当 有 新 的 Se kube-dns 2: ffs 
加 该 Service 的 DNS 记录 。 e be 过 <SERVICE_NAME>. 
<NAMESPACE NAME> 访 问 Service。 


比如 可 以 用 httpd-svc.default 访 问 Service httpd-svc， 如 图 6-13 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl run busybox --rm -ti --image=busybox /bin/sh 
If you don't see a command prompt, try pressing enter. 

/# 


/ € wgetlhttpd-svc.default:8080 
Connecting to httpd-svc. Sp 8080 (10.99.229.179:8080) 
index.html 100% 45 0:00:00 ETA 


图 6-13 


如 上 所 示 ， 我 们 在 一 个 临时 的 busybox Pod 中 验证 了 DNS 的 有 效 性 。 另 
由 于 这 个 Pod 与 httpd-svc 同 属于 default namespace， 因 此 可 以 省 略 
default 直 接 用 httpd-svc 访 问 Service， 如 图 6-14 所 示 。 


/# 
/ € wgetlhttpd-svc:8080 


Connecting to httpd-svc:8080 (10.99.229.179:8080) 
100% 


index.html 
/ # 


图 6-14 
用 nslookup 查 看 httpd-svc 的 DNS 信息 ， 如 图 6-15 所 示 。 


/ # 

/ # nslookup httpd-svc 

Server: 10.96.0.10 

Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster. local 


Name: httpd-svc 
Address 1: 10.99.229.179 httpd-svc.default.svc.cluster. local 
ZEN 


图 6-15 


DNS 服务 器 是 kube-dns.kube-system.svc.clusterlocal , 3x Sz Pr E Lx 
kube-dns 20 (F, € AX Bb x ib TE kube-system namespace 中 的 一 个 
Service ° 


httpd-svc.default.svc.cluster.local 是 httpd-svc 的 完整 域名 。 


如 果 要 访问 其 他 namespace 中 的 Service NL iE Fnamesapce 了。 
kubectl get namespace 查 看 已 有 的 namespace， 如 图 6-16 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get namespace 
NAME STATUS AGE 

default Active 5d 


kube-public Active 5d 
kube-system Active 5d 
ubuntu@k8s-master : ~$ 


图 6-16 


在 kube-public 中 部 署 Service httpd2-svc， 配 置 如 图 6-17 所 示 。 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 

name: httpd2 

namespace: kube- 
spec: 

replicas: 

template: 

metadata: 

labels: 
run: httpd2 

spec: 

containers: 

- name: httpd2 
image: httpd 
ports: 

- containerPort: 


apiVersion: v1 
kind: Service 
metadata: 
name: httpd2-svc 
namespace: kube-public 
spec: 
selector: 
run: httpd2 
ports: 
- protocol: TCP 
port: 
targetPort: 


图 6-17 


通过 namespace: kube-public 指 定 质 源 所 属 的 namespace。 多 个 质 源 可 以 
在 一 个 YAML 文 件 中 定义 ， 用 “---” 分 割 。 执 行 kubectl apply 8 & 5t 18, 
如 图 6-18 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl apply -f httpd2.yml 
deployment "httpd2" created 


service "httpd2-svc" created 
ubuntu@k8s-master: ~$ 


图 6-18 


查看 kube-public 的 Service， 如 图 6-19 所 示 。 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ kubectl get service --namespace-kube-public 
NAME CLUSTER-IP EXTERNAL- IP PORTCS) AGE 


httpd2-svc 100.103.198.189 <none> 8080/TCP 2m 
ubuntu@k8s-master : ~$ 


图 6-19 


在 busybox Pod 中 访问 httpd2-svc， 如 图 6-20 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl run busybox --rm -ti --image=busybox /bin/sh 
If you don't see a command prompt, try pressing enter. 

/ # 

/ # wget wget httpd2-svc:8080 

wget: bad address 'wget' 

/ # 


/ # wget httpd2-svc.kube-public: 8080 


图 6-20 
为 不 属于 同一 个 namespace， 所 以 必须 使 用 httpd2-svc.kube-public 才 
能 访问 到 。 


6.4 ”外 网 如 何 访问 Service 


除了 Cluster 内 部 可 以 访问 Service , 很 多 情况 下 我 们 也 希望 应 用 的 
Service 能 够 暴露 给 Cluster 外 部 。Kubernetes 提 供 了 多 种 类 型 的 Service， 
上 默认 是 ClusterIP。 

(1) ClusterIP 


Service 通 过 Cluster 内 部 的 IP 对 外 提供 服务 ， 只 有 Cluster 内 的 节点 和 Pod 
可 访问 ， 这 是 默认 的 Service 类 型 ， 前 面 实验 中 的 Service 都 是 
ClusterIP ° 

(2) NodePort 


Service 通 过 Cluster 节 点 的 静态 端口 对 外 提供 服务 。Cluster 外 部 可 以 通 
过 <NodeIP>:<NodePort> 访 问 Service ° 


(3) LoadBalancer 


Service FI] Ff cloud provider #4 AJ load balancer 对 外 提供 服务 cloud 
provider 负责 将 load balancer 84) Vit = &r F] Service ° H BI x $$ AY cloud 
provider GCP ` AWS ` Azur® ° 


下 面 我 们 来 实践 NodePort，Service httpd-svc 的 配置 文件 修改 如 图 6-21 
所 示 。 


apiVersion: v1 
kind: Service 
metadata: 

name: httpd-svc 


spec: 
type: NodePort 
selector: 


run: httpd 
ports: 
- protocol: TCP 
port: 
targetPort: 


图 6-21 


添加 type: NodePort， 重 新 创建 httpd-svc， 如 图 6-22 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f httpd-svc.yml 
service "httpd-svc" created 

ubuntu@k8s-master : ~$ 


ubuntu@k8s-master:~$ kubectl get service httpd-svc 

NAME CLUSTER-IP EXTERNAL-IP PORTCS AGE 
httpd-svc 10.109.144.35 |<nodes> 8080:32312/TCP | 5s 
ubuntuék8s master : ~$ 


图 6-22 
Kubernetes 依 然 会 为 httpd-svc 分 配 一 个 ClusterIP， 不 同 的 是 : 


(1) EXTERNAL-IP 为 nodes， 表 示 可 通过 Cluster 每 个 节点 自身 的 IP 访 
la] Service ° 


(2) PORT(S) 为 8080:32312。8080 是 ClusterIP 监 听 的 端口 ，32312 则 是 
节点 上 监听 的 端口 。 Kubernetes 会 从 30000 一 32767 中 人 分 本 一 个 可 用 的 
端口 ， 每 个 节点 都 会 监听 此 端口 并 将 请 求 转发 给 Service， 如 图 6-23 所 


人 


一 


o 


4 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ netstat -anlgrep 32312 


tcp6 0 0 :::32312 Per LISTEN 
ubuntu@k8s-master : ~$ 


图 6-23 


下 面 测试 NodePort 是 否 正 常 工 作 ， 如 图 6-24 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ curl 192.168.56.105:32312 
«html»«body»«hi»It works! </h1></body></htm1> 
ubuntu@k8s-master: ~$ 

ubuntu@k8s-master:~$ curl 192.168.56.106:32312 
<html><body><hi>It works! </h1></body></html1> 
ubuntu@k8s-master: ~$ 

ubuntu@k8s-master:~$ curl 192.168.56.107:32312 
<html><body><hi>It works! </h1></body></htm1> 
ubuntu@k8s-master: ~$ 


图 6-24 
通过 三 个 和 点 IP+32312 端 口 都 能 够 访问 httpd-svc。 


接 下 来 我 们 深入 探讨 一 个 问题 : Kubernetes 是 如 何 将 <NodeIP>: 
«NodePort^ B £l Pod YE? 


与 ClusterIP 一 样 ， 也 是 借助 了 iptables。 与 ClusterIP 相 比 ， 每 个 和 点 的 
iptables 中 都 增加 了 下 面 两 条 规则 ， 如 图 6-25 所 示 。 


-A KUBE-NODEPORTS -p tcp -m comment -comment “default/httpd-svc: ” -m tcp --dport 32312 -j KUBE-MARK-M 
ASQ 


一 


-A KUBE-NODEPORTS -p tcp -m comment -comment “default/httpd-svc: ” -m tcp --dport 32312 -j KUBE-SVC-RL 
3JAE4GN7VOGDGP 


图 6-25 


规则 的 含义 是 : 访问 当前 节点 32312 端 口 的 请 求 会 应 用 规则 KUBE- 
SVC-RL3JAE4GN7VOGDGP， 内 容 如 图 6-26 所 示 。 


-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment “default/httpd-svc: " -m statistic -mode random -prob 
ability 0.33332999982 -j KUBE-SEP-C5KB52P4BBJQ35PH 
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment “default/httpd-svc: " -m statistic -mode random -prob 


ability 0.50000000000 -j KUBE-SEP-HGVKQQZZCF7RV41T 
-A KUBE-SVC-RL3JAE4GN7VOGDGP -m comment -comment “default/httpd-svc: ” -j KUBE-SEP-XE25WGVXLHEIRVO5 


图 6-26 


其 作用 束 是 负载 均衡 到 每 一 个 Pod。 


NodePort 默 认 的 是 随机 选择 ， 不 过 我 们 可 以 用 nodePort 指 定 某 个 特定 端 
口 ， 如 图 6-27 所 示 。 


apiVersion: v1 
kind: Service 
metadata: 

name: httpd-svc 
spec: 

type: NodePort 

selector: 


run: httpd 
ports: 
- protocol: TCP 
port: 
targetPort: 


图 6-27 
现在 配置 文件 中 就 有 三 个 Port 了 : 


。 nodePort 是 廊 点 上 监听 的 端口 。 
。 port 是 ClusterIP 上 监听 的 端口 。 
。targetPort 是 Pod 监 听 的 端口 。 


最 终 ，Node 和 ClusterIP 在 各 目 端口 上 接收 到 的 请 求 都 会 通过 iptables 转 
发 到 Pod 的 targetPort ° 


应 用 新 的 nodePort 并 验证 ， 如 图 6-28 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f httpd-svc.yml 
service "httpd-svc" configured 

ubuntuek8s master : ~$ 

ubuntu@k8s-master:~$ kubectl get service httpd-svc 
NAME CLUSTER- IP EXTERNAL-IP PORT(S) 
httpd-svc  10.109.144.35 <nodes> 8080:30000/TCP 
ubuntuék8s master : ~$ 

ubuntu@k8s-master:~$ curl 192.168.56.105:30000 
«html»«body»«h1»It works!«/h1»«/body»«/html» 
ubuntu@k8s-master:~$ curl 192.168.56.106:30000 
<htmL><body><h1i>It works!</h1></body></htm1> 
ubuntuék8s-master:-$ curl 192.168.56.107:30000 
«html»«body»«h1»It works!«/h1»«/body»«/html» 
ubuntuék8s-master : ~$ 


图 6-28 


nodePort: 30000 已 经 生效 了 。 


65 ”小结 
本 章 我 们 讨论 访问 应 用 的 机 制 Service ， 学 习 了 如 何 创建 Service , 


Service 的 三 种 类 型 ClusterIP、NodePort 和 LoadBalancer， 以 及 它们 各 自 
的 适用 场景 。 


第 7 间 Rolling Update 
滚动 更 新 是 一 次 只 更 新 一 小 部 分 副本 ， 成 功 后 再 更 新 更 多 的 副本 ， 最 


终 完 成 所 有 副本 的 更 新 。 滚 动 更 新 的 最 大 好 处 是 零 停 机 ， 整 个 更 新 过 
程 始终 有 副本 在 运行 ， 从 而 保证 了 业务 的 连续 性 。 


71 实践 


下 面 我 们 部 署 三 副本 应 用 ， 初 始 镜像 为 httpd:2.2.31， 然 后 将 其 更 新 到 
httpd:2.2.32 ° 


httpd:2.2.31 的 配置 文件 如 图 7-1 所 示 。 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 
name: httpd 
spec: 
replicas: 
template: 
metadata: 
Labels: 
run: httpd 
spec: 
containers: 
- name: httpd 
ports: 
- containerPort: 


图 7-1 


通过 kubectl apply 部 署 ， 如 图 7-2 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f httpd.yml 

deployment "httpd" created 

ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get deployment httpd -o wide 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINER(S) SELECTOR 
httpd 3 3 3 3 8s httpd httpd:2.2.31] run=httpd 
ubuntu@k8s-master :~$ 

ubuntu@k8s-master:~$ kubectl get replicaset -o wide 

NAME DESTRED CURRENT READY AGE CONTAINER(S) SELECTOR 
httpd-551879778 3 3 3 13s $2.2. pod-template-hash-55 
ubuntuek8s-master:-$ 

ubuntuék8s-master:-$ kubectl get pod 

NAME READY STATUS RESTARTS AGE 

httpd-551879778- jkxn4 1/1 Running 19s 

httpd-551879778-n3sqv 1/1 Running 19s 

httpd-551879778-zdfkt 1/1 Running 19s 

ubuntu@k8s-master :~$ 


图 7-2 
部 署 过 程 如 下 : 
(1) 创建 Deployment httpd * 
(2) 创建 ReplicaSet httpd-551879778 ° 
(3) 创建 三 个 Pod。 


(4) 当前 镜像 为 httpd:2.2.31 ° 


将 配置 文件 中 的 httpd:2.2.31 蔡 换 为 httpd:2.2.32， 再 次 执行 kubectl 
apply， 如 图 7-3 所 示 。 


ona master: -$ kubectl apply -f httpd.yml 
deployment "httpd" configured 

ubuntu@k8s-master: ~$ 

ubuntu@k8s-master:~$ kubectl get deployment httpd -o wide 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERCS) IMAGE(S) SELECTOR 
httpd 3 3 3 3 1m httpd httpd:2.2.32] run=httpd 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ kubectl get replicaset -o wide 
NAME DESIRED CURRENT READY AGE CONTAINERCS) IMAGECS) SELECTOR 


httpd-1276601241 3 3 3 9s httpd http 32] pod-template-hash 
httpd-551879778 0 0 0 2m httpd httpd:2.2.31] pod-template-hash: 
ubuntu@k8s-master: ~$ 

ubuntu@k8s-master:~$ kubectl get pod 

NAME READY STATUS RESTARTS 


httpd-1276601241-26jx3 1/1 Running 0 
httpd-1276601241-27kh7 1/1 Running 0 
httpd-1276601241-pwrt7 1/1 Running 0 
ubuntu@k8s-master: ~$ 


图 7-3 
我 们 发 现 了 如 下 变化 : 
(1) Deployment httpd 的 镜像 更 新 为 httpd:2.2.32。 


(2) 新 创建 了 ReplicaSet httpd-1276601241， 镜 像 为 httpd:2.2.32， 并 且 
管理 了 三 个 新 的 Pod 。 


(3) 之 前 的 ReplicaSet httpd-551879778 里 面 已 经 没有 任何 Pod。 


结论 是 : ReplicaSet httpd-551879778 的 三 个 httpd:2.2.31 Pod 已 经 被 
ReplicaSet Pe 1276601041 B= 4 httpd:2.2.32 Pod 替 换 了 。 


具体 过 程 可 以 通过 kubectl describe deployment httpd 查 看 ， 如 图 7-4 所 
= o 


From SubObjectPath Type Reason Message 


deployment-controller Normal ScalingReplicaSet p replica set httpd-551879778 to 3 

deployment-controller Normal ScalingReplicaSet Scaled up replica set httpd-1276601241 to 1 
deployment-controller Normal ScalingReplicaSet Scaled down replica set httpd-551879778 to 2 
deployment-controller Normal ScalingReplicaSet Scaled up replica set httpd-1276601241 to 2 
deployment-controller Normal ScalingReplicaSet Scaled down replica set httpd-551879778 to 1 
deployment-controller Normal ScalingReplicaSet Scaled up replica set httpd-1276601241 to 3 
deployment-controller Normal ScalingReplicaSet Scaled down replica set httpd-551879778 to 0 


图 7-4 


每 次 只 更 新 替换 一 个 Pod: 


H 


(1) ReplicaSet httpd-1276601241 增 加 一 个 Pod， 总 数 为 1 。 
(2) ReplicaSet httpd-551879778 减 少 一 个 Pod， 总 数 为 2。 
(3) ReplicaSet httpd-1276601241 增 加 一 个 Pod， 总 数 为 2。 
(4) ReplicaSet httpd-551879778 减 少 一 个 Pod， 总 数 为 1。 
(5) ReplicaSet httpd-1276601241 增 加 一 个 Pod， 总 数 为 3。 
(6) ReplicaSet httpd-551879778 减 少 一 个 Pod， 总 数 为 0。 
每 次 蔡 换 的 Pod 数 量 是 可 以 定制 的 。Kubernetes 提 供 了 两 个 参数 


maxSurge 和 maxUnavailable 来 精细 控制 Pod 的 奉 换 数量 ， 我 们 将 在 后 面 
结合 Health Check 特 性 一 起 讨论 。 


7.2 E 
kubectl apply 每 次 更 新 应 用 时 ，Kubernetes 都 会 记录 下 当前 的 配置 ， 保 
存 为 一 个 revision (X). ， 这 样 就 可 以 回 深 到 某 个 特定 revision。 


默认 配置 下 ，Kubernetes 只 会 保留 最 近 的 儿 个 revision， 可 以 在 
Deployment 配 置 文件 中 通过 revisionHistoryLimit 属 性 增加 revision 数 
Bo 


下 面 实践 回 滩 功 能 。 应 用 有 三 个 配置 文件 ， 即 httpd.vl.yml、 
httpd.v2.yml 和 httpd.v3.yml， 分 别 对 应 不 同 的 httpd 镜 像 2.4.16、2.4.17 和 
2.4.18， 如 图 7-5、 图 7-6、 图 7-7 所 示 。 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 
name: httpd 
spec: 
revisionHistoryLimit: 
replicas: 
template: 
metadata: 
Labels: 
run: httpd 
spec: 
containers: 


image: httpd:2.4.16 


- containerPort: 


图 7-5 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 
name: httpd 
spec: 
revisionHistoryLimit: 
replicas: 
template: 
metadata: 
labels: 
run: httpd 
spec: 
containers: 
- name: httpd 
ports: 
- containerPort: 


图 7-6 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 
name: httpd 
spec: 
revisionHistoryLimit: 
replicas: 
template: 
metadata: 

labels: 
run: httpd 

spec: 

containers: 

- name: httpd 
image: http 
ports: 

- containerPort: 


图 7-7 


通过 kubectl apply 部 效 并 更 新 应 用 ， 如 图 7-8 所 示 。 


ubuntuek8s-master:-$ 

ubuntu@k8s-master:~$ kubectl apply -f httpd.v1.yml (z-record) 

deployment "httpd" created 

ubuntuek8s -master : ~$ 

ubuntu@k8s-master:~$ kubectl get deployment httpd -o wide 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERCS) IMAGE(S) SELECTOR 
httpd 3 3 3 3 8s httpd run=httpd 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl apply -f httpd. v2.yml (C-record) 

deployment "httpd" configured 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get deployment httpd -o wide 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERCS) IMAGE(S) SELECTOR 
httpd 3 3 3 3 27s httpd run-httpd 
ubuntuék8s master : ~$ 

ubuntu@k8s-master:~$ kubectl apply -f httpd.v3.yml 

deployment "httpd" configured 

ubuntuek8s-master:-$ 

ubuntuek8s-master:-$ kubectl get deployment httpd -o wide 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERCS) IMAGE(S) SELECTOR 
httpd 3 3 3 3 51s httpd run-httpd 
ubuntuek8s-master:-$ 


图 7-8 


-record 的 作用 是 将 当前 命令 令 记 录 到 revision 记 录 中 ， 这 样 我 们 就 可 以 知 
道 每 个 revison 对 应 的 是 哪个 配置 文件 了 。 通 过 kubectl rollout history 
deployment httpd t & os 史记 录 ， 如 图 7-9 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl rollout history deployment httpd 
deployments "httpd" 

REVISION CHANGE - CAUSE 


kubectl apply --filename-httpd.v1.yml --record=true 
kubectl apply --filename-httpd.v2.yml --record-true 
kubectl apply --filename-httpd.v3.yml --record-true 


ubuntu@k8s-master : ~$ 
图 7-9 


CHANGE-CAUSE 就 是 --record 的 结果 。 如 果 要 回 深 到 某 个 版 本 ， 比 如 
revision 1， 可 以 执行 命令 kubectl rollout undo deployment httpd --to- 
revision=1， 如 图 7-10 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl rollout undo deployment httpd --to-revision=1 


ubuntu@k8s-master:~$ kubectl get deployment httpd -o wide 


DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERCS) IMAGECS SELECTOR 
3 S 3 8m httpd run=httpd 


图 7-10 


此 时 ，revison 历 史记 录 也 会 发 生 相 应 变化 ， 如 图 7-11 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl rollout history deployment httpd 
deployments "httpd" 

REVISION CHANGE-CAUSE 


kubectl apply --filename-httpd.v2.yml --record=true 
kubectl apply --filename-httpd.v3.yml --record-true 
kubectl apply --filename-httpd.v1.yml --record-true 


ubuntu@k8s-master : ~$ 


图 7-11 
revison 125 Bi, f revison 4。 不 过 我 们 可 以 通过 CHANGE-CAUSE 知 道 每 


个 revison 的 具体 含义 ， 所 以 一 定 要 在 执行 kubectl apply 时 加 上 --record 


73 ”小结 


本 章 我 们 学 习 了 滚动 更 新 。 滚 动 更 新 采用 渐进 的 方式 逐步 奉 换 旧版 本 
Pod。 如果 更 新 不 如 预期 ， 可 以 通过 回 深 操作 恢复 到 更 新 前 的 状态 。 


第 8 章 Health Check 


强大 的 自 愈 能力 是 Kubernetes 这 类 容器 编排 引 警 的 一 个 重要 特性 。 自 
愈 的 默认 实现 方式 是 自动 重启 发 生 故 障 的 容器 。 除 此 之 外 ， 用 户 还 可 
a i i: : n Readiness 探 测 机 制 设置 更 精细 的 健康 检查 ， 进 而 实 
现 如 下 需求 : 


) 
(2) 避免 部 署 无 效 的 镜像 。 
) 更 加 安全 的 滚动 升级 。 


下 面 通过 实践 学 习 Kubernetes 的 Health Check 功 能 。 


8.1 默认 的 健康 检查 


我 们 首先 学 习 Kubernetes 默 认 的 健康 检查 机 制 ， 每 个 容器 局 动 时 都 会 
执行 一 个 进程 ， 此 进程 由 Dockerfile 的 CMD 或 ENTRYPOINT 指 定 。 如 
果 进 程 退 出 时 返回 码 非 零 ， 则 认为 容 絮 发 生 故 障 ，Kubernetes 就 会 根 


JR BA 


据 restartPolicy 重 局 容器 ° 
下 面 我 们 模拟 一 个 容器 发 生 故 障 的 场景 ，Pod 配 置 文件 如 图 8-1 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 
labels: 
test: healthcheck 
name: healthcheck 
spec: 


restartPolicy: OnFailure 


containers: 

- name: healthcheck 
image: busybox 
args: 

- /bin/sh 


- -C 


- sleep 10; exit 


图 8-1 


Pod 的 restartPolicy 设 置 为 OnFailure， 默 认为 Always。 
sleep 10; exit 1 模拟 容 恬 启动 10 秒 后 发 生 故 障 。 


执行 kubectl apply 创 建 Pod， 命 名 为 healthcheck， 如 图 8-2 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl apply -f healthcheck.yml 


pod "healthcheck" created 
ubuntuek8s-master : ~$ 


图 8-2 


过 几 分 钟 查看 Pod 的 状态 ， 如 图 8-3 所 示 。 


ubuntu@k8s-master: ~$ 

ubuntu@k&8s-master:~$ kubectl get pod healthcheck 
NAME READY STATUS RESTARTS AGE 
healthcheck 1/1 Running 3 im 


ubuntu@k8s-master: ~$ 


图 8-3 

可 看 到 容 骨 当前 已 经 重启 了 3 次 。 

在 上 面 的 例子 中 ， 容 器 进程 返回 值 非 零 ，Kubernetes 则 认为 容器 发 生 
故障 ， 需 要 重启。 有 不 少 情况 是 发 生 了 故障 ， 但 进程 并 不 会 退出 。 比 
如 访问 Web 服 务 絮 时 显示 500 内 部 错误 ， 可 能 是 系统 超载 ， 也 可 能 是 资 
源 死 锁 ， 此 时 httpd 进 程 并 没有 异常 退出 ， 在 这 种 情况 下 重启 容器 可 能 
是 最 和 直接、 最 有 歼 的 解决 方案 ， 那 我 们 如 何 利 用 Health Check 机 制 来 处 
理 这 类 场景 呢 ? 


答案 就 是 Liveness 探 测 。 


8.2 ”Liveness 探 测 


Liveness 探 测 让 用 户 可 以 目 定 义 判 断 容 器 是 否 健 康 的 条 件 。 如 果 探 测 
失败 ，Kubernetes 就 会 重启 容器 。 


下 面 举例 说 明 ， 创 建 Pod， 如 图 8-4 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 
labels: 
test: liveness 
name: liveness 


spec: 
restartPolicy: OnFailure 
containers: 
- name: liveness 


image: busybox 
args: 
- /bin/sh 


- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 
livenessProbe: 
exec: 
command : 
= cat 
- /tmp/healthy 
initialDelaySeconds: 
periodSeconds: 


图 8-4 


启动 进程 首先 创建 文件 /tmp/healthy，30 秒 后 删除 ， 在 我 们 的 设 定 中 ， 
aes , WAAR T EN AS. KZE Be 
B 。 


livenessProbe 部 分 定义 如 何 执行 Liveness 探 测 : 
(1) 探测 的 方法 是 : 通过 cat 命 令 检 查 /tmp/healthy 文 件 是 否 存在 。 如 


果 命 令 执 行 成 功 ， 返 回 值 为 零 ，Kubernetes 则 认为 本 次 Liveness 探 测 成 
功 ; 如 果 命 令 返 回 值 非 零 ， 本 次 Liveness 探 测 失 败 。 


(2) initialDelaySeconds: 10 指 定 容器 启动 10 之 后 开始 执行 Liveness 探 
测 ， 我 们 一 般 会 根据 应 用 启动 的 准备 时 间 来 设置 。 比 如 某 个 应 用 正常 
启动 要 花 30 秒 ， 那 么 initialDelaySeconds 的 值 就 应 该 大 于 30。 


(3) periodSeconds: 5 指定 每 5 秒 执行 一 次 Liveness 探 测 。Kubernetes 如 
宁 连 续 执 行 3 次 Liveness 探 测 均 失 败 ， 则 会 杀 掉 并 重启 容器 。 


下 面 创建 Pod liveness， 如 图 8-5 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ kubectl apply -f liveness.yml 


pod "liveness" created 
ubuntuék8s master: ~$ 


图 8-5 


从 配置 文件 可 知 ， 最 开始 的 30 秒 ，/tmp/healthy 存 在 ，cat 命 令 返 回 0， 
Liveness 探 测 成 功 ， 这 段 时 间 kubectl describe pod liveness 的 Events 部 分 
会 显示 正常 的 日 志 ， 如 图 8-6 所 示 2 


Reason Message 


Scheduled Successfully assigned liveness to k8s-nodel 


SuccessfulMountVolume MountVolume.SetUp succeeded for volume "default-token-hnz?b" 
Pulling pulling image “busybox" 

Pulled Successfully pulled image "busybox" 

Created Created container 


图 8-6 


35 秒 之 后 ， 日 志 会 显示 /tmp/healthy 已 经 不 存在 ，Liveness 探 测 失 败 。 
再 过 儿 十 秒 ， 几 次 探测 都 失败 后 ， 容 右 会 锐 重 局 ， 如 图 8-7、 图 8-8 所 
ZN o 


odel 
e "default-token-hnz7b" 
en '/tmp/healthy': No such file 


Normal Pulling pulling ima usybox 
Normal Killing Killing container wi 


Norma ull cce: e 
Normal Created Created container 
Norm container 


ubuntu@k8s-master : ~$ 


ubuntu@k8s-master:~$ kubectl get pod liveness 
NAME READY STATUS RESTARTS AGE 
liveness 1/1 Running (1 1m 


ubuntu@k8s-master: ~$ 


图 8-8 


8.3 “Readiness 探 测 


除了 Liveness 探 测 , Kubernetes Health Check 机 制 还 包括 Readiness 探 
测 。 


用 户 通 过 Liveness 探 测 可 以 告诉 Kubernetes 什 么 时 候 通 过 重启 容器 实现 
自 愈 ; Readiness 探 测 则 是 告诉 Kubernetes 什 么 时 候 可 以 将 容器 加 入 到 


Service 负 载 均衡 池 中 ， 对 外 提供 服务 。 


Readiness 探 测 的 配置 语法 与 Liveness 探 测 完 
所 示 。 


apiVersion: vi 
kind: Pod 
metadata: 
labels: 
test: readiness 
name: readiness 


spec: 
restartPolicy: OnFailure 
containers: 
- name: readiness 
image: busybox 


args: 
- /bin/sh 
= -Ç 


- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 


exec: 

command: 

= cat 

- /tmp/healthy 
initialDelaySeconds: 
periodSeconds: 


图 8-9 


个 配置 文件 只 是 将 前 面 例 子 中 的 liveness 赫 换 为 了 readiness， 


车 有 有 什么 下 同 的 效 霖 ， 如 图 8-10 所 示 。 


ubuntu@k8s-master:~$ kubectl apply -f readiness. 


pod "readiness" created 

ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get pod readiness 
NAME R STATUS RESTARTS [AGE 
readiness Hra Running 0 


ubuntu@k8s-master:~$ 


ubuntu@k8s-master:~$ kubectl get pod readiness 


NAME READY STATUS RESTARTS AGE 
readiness brad Running 0 
ubuntu@k8s-master: ~$ 

ubuntu@k8s-master:~$ kubectl get pod readiness 


NAME READY STATUS RESTARTS AGE 
readiness |Q/1 Running 0 53s 


ubuntu@k8s-master: ~$ 


图 8-10 


一 样 ， 如 图 8-9 中 的 例子 


我 们 看 


Pod readiness 的 READY 状 态 经 历 了 如 下 变化 : 
(1) 刚 被 创建 时 ，READY 状 态 为 不 可 用 。 


(2) 15 秒 后 (initialDelaySeconds + periodSeconds) ， 第 一 次 进行 
Readiness 探 测 并 成 功 返 回 ， 设 置 READY 为 可 用 。 


(3) 30 秒 后 ，/tmp/healthy 被 删除 ， 连 续 3 次 Readiness 探 测 均 失败 后 ， 
READY 被 设置 为 不 可 用 。 


通过 kubectl describe pod readiness 也 可 以 看 到 Readiness 探 测 失 败 的 日 
志 ， 如 图 8-11 所 示 。 


Scheduled Successfully assigned readiness to k8s-nodel 
SuccessfulMountVolume ^ MountVolume,SetUp succeeded for volume "default-token-hnz7b" 
Pulling ulli i " 


ng image “busybox 
Successfully pulled image "busybox" 
eated container 
Started container 
Readiness probe failed: cat: can't open '/tmp/healthy':|No such file 


图 8-11 
下 面 对 Liveness 探 测 和 Readiness 探 测 做 个 比较 : 


(1) Liveness 探 测 和 Readiness 探 测 是 两 种 Health Check 机 制 ， 如 果 不 
特意 配置 ，Kubernetes 将 对 两 种 探测 采取 相同 的 默认 行为 ， 即 通过 判 
上 晰 容 老 局 动 进程 的 返回 值 是 否 为 去 来 判断 探测 是 否 成 功 。 


(2) 两 种 探测 的 配置 方法 完全 一 样 ， 支 持 的 配置 参数 也 一 样 。 不 同 之 
处 在 于 探测 失败 后 的 行为 ，Liveness 探 测 是 重启 容器 ;Readiness 探 测 
则 是 将 容器 设置 为 不 可 用 ， 不 接收 Service 转 发 的 请 求 。 


(3) Liveness 探 测 和 Readiness 探 测 是 独立 执行 的 ， 二 者 之 间 没 有 依 
赖 ， 所 以 可 以 单独 使 用 ， 也 可 以 同时 使 用 。 用 Liveness 探 测 判 断 容 恬 
是 否 需 要 重启 以 实现 自 愈 ， 用 Readiness 探 测 判 断 容 器 是 否 已 经 准备 好 
对 外 提供 服务 。 


理解 了 Liveness 探 测 和 Readiness 探 测 的 原理 ， 接 下 来 讨论 如 何在 业务 
场景 中 使 用 Health Check ° 


8.4 Health Check # Scale Up 中 的 应 
用 


对 于 多 副本 应 用 ， 当 执行 Scale Up 操作 时 ， 新 副本 会 作为 backend 被 添 
加 到 Service 的 负载 均衡 中 ， 与 已 有 副本 一 起 处 理 客 户 的 请 求 。 考 虑 到 
应 用 局 动 递 名 都 和 需要 一 个 准备 阶段 比如 加 载 缓存 数据 、 连 接 数据 库 
从 容器 启动 到 真正 能 够 提供 服务 是 需要 一 段 时 间 的 。 我 们 可 以 通 
Theine AAEE WERA, WER OK AIK EDS AE 6 
backend ° 


示例 应 用 的 配置 文件 如 图 8-12 所 示 。 


apiVersion: apps/vibetal 


replicas: 
template: 
metadata: 
Labels: 
run: web 
spec: 
containers: 
- name: web 
image: myhttpd 
ports: 
- containerPort: 
| readinessProbe: 
httpGet: 
scheme: HTTP 
path: /healthy 
port: 
initialDelaySeconds: 
periodSeconds: 


apiVersion: v1 
kind: Service 
metadata: 

name: web-svc 


spec: 
selector: 
run: web 
ports: 
- protocol: TCP 
port: 
targetPort: 


图 8-12 


重点 关注 readinessProbe 部 分 。 这 里 我 们 使 用 了 不 同 于 exec 的 另 一 种 探 
测 ii 法 httpGet。Kubernetes 对 于 该 方法 探测 成 功 的 判断 条 件 是 http 请 求 
的 返回 代码 在 200~-400 之 间 。 


e schema 指 定 协议 ， 支 持 HTTP (默认 值 ) 和 HTTPS。 
e. path 指 定 访问 路 径 。 
。 port 指 定 端 口 。 

上 面 配 置 的 作用 是 : 

(1) 容器 启动 10 秒 之 后 开始 探测 。 


(2) 4 ehttp://[container_ip]:8080/healthy1 [5] (0137 200~400, # 
WAAMA, BK Service web-svc 的 请 求 。 


(3) 每 隔 5 秒 探测 一 次 。 


(4) 直到 返回 代码 为 200~“400， 表 明 容 器 已 经 就 绪 ， 然 后 将 其 加 入 到 
web-svc 的 负载 均衡 中 ， 开 始 处 理 客户 请 求 。 


(5) 探测 会 继续 以 5 秒 的 间 隅 执行 ， 如 果 连 续 发 生 3 次 失败 ， 容 器 又 会 
从 人 负载 均衡 中 移 除 ， 直 到 下 次 探测 成 功 重 新 加 入 。 


对 于 http://[container_ip]:8080/healthy， 应 用 则 可 以 实现 自己 的 判断 逻 
辑 ， 比 如 检查 所 依赖 的 数据 库 是 否 惑 绪 ， 示 例 代 码 如 图 8-13 所 示 。 


http .HandleFunc( , func(w http.ResponseWriter, r *http.Request) { (1 


healthy = True; 


// Check Database l 
db = connect(dbIP, dbPort, dbUser, dbPassword) (2 


if db != NULL { 
try { 
db. QueryC 
} catch (e){ 
err = e.message 


} 


if db == NULL || err != NULL { 
healthy = False 
errMsg += 


} 


if healthy { 
w.WriteC[lbyteC pw ce! 
} else { 
// Send 
http.Error(w, errMsg, http.StatusServiceUnavailable) 


12; 


http.ListenAndServe(C 


图 8-13 
(D 定义 /healthy 的 处 理 函 数 。 
@ 连接 数据 库 并 执行 测试 SQL ° 
@ 测试 成 功 ， 正 第 返 回 ， 人 代码 200 。 
@ 测试 失败 ， 返 回 错误 代码 503 。 
© 在 8080 端 口 监听 。 


对 于 生产 环境 中 重要 的 应 用 ， 都 建议 配置 Health Check， 保 证 处 理 客 户 
请 求 的 容 絮 都 是 准备 就 绪 的 Service backend ° 


8.5 Health Check 在 深 动 更 新 中 的 应 
用 


Health Check 男 一 个 重要 的 应 用 场景 是 Rolling Update。 试想 一 下 ， 现 
有 一 个 正常 运行 的 多 副本 应 用 ， 接 下 来 对 应 用 进行 更 新 (比如 使 用 更 
高 版 本 的 image) ，Kubernetes 会 启动 新 副本 ， 然 后 发 生 了 如 下 事件 : 


(1) 正常 情况 下 新 副本 需要 10 秒 钟 完成 准备 工作 ， 在 此 之 前 无 法 响应 
业务 请 求 。 

(2) 由 于 人 为 配置 错误 ， 副 本 始终 无 法 完成 准备 工作 (比如 无 法 连接 
后 端 数据 库 ) 。 


先 别 继续 往 下 看 ， 现 在 请 花 一 分 钟 思 考 这 个 问题 : 如 果 没 有 配置 
Health Check， 会 出 现 怎样 的 情况 ? 


因为 新 副本 本 号 没 有 异 和 退 出 ， 罗 认 的 Health Check 机 制 会 认为 容器 已 
Raa, UMAR AAU ARIA, HER ie: 当 所 有 旧 
BANA BCS HS, BAMAR EERE RK, FOIA Tob be PEARS ^ ON 
条 这 是 发 生 在 重要 的 生产 系统 上 ， 后 采 会 非常 广 重 。 


如 采 正 确 配 置 了 Health Check， 痢 副本 只 有 通过 了 Readiness 探 测 才 会 被 
添加 到 Service; 如 果 没 有 通过 探测 ， 现 有 副本 不 会 被 全 部 替换 ， 业 务 
仍然 正常 进行 。 

下 面 通过 例子 来 实践 Health Check 在 Rolling Update 中 的 应 用 。 

使 用 如 下 配置 文件 app.vl.yml 模 拟 一 个 10 副 本 的 应 用 ， 如 图 8-14 所 示 。 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 
name: app 
spec: 
replicas: 
template: 
metadata: 
labels: 


run: app 
spec: 
containers: 


- name: app 
image: busybox 
args: 
- /bin/sh 
- =C 
- sleep 10; touch /tmp/healthy; sleep 
readinessProbe: 
exec: 
command : 
= Cat 
- /tmp/healthy 
initialDelaySeconds: 
periodSeconds: 


图 8-14 


10 秒 后 副本 能 够 通过 Readiness 探 测 ， 如 图 8-15 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f app.v1.yml --record 
deployment "app" created 

ubuntu@k8s-master: ~$ 

ubuntu@k8s-master:~$ kubectl get deployment app 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
app 10 10 10 10 28s 
ubuntuek8s -master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod 

NAME READY STATUS RESTARTS 
app-2780995820-Ompfl 1/1 Running 
app-2780995820-9nmfm 1/1 Running 
app-2780995820-dqdwn 1/1 Running 
app-2780995820-g@srs 1/1 Running 
app-2780995820-g52wp 1/1 Running 
app-2780995820-kddms 1/1 Running 
app-2780995820-rrwsh 1/1 Running 
app-2780995820-t3k14 1/1 Running 
app-2780995820-vigqzn 1/1 Running 
app-2780995820-z8qx4 1/1 Running 
ubuntu@k8s-master: ~$ 


0 
0 
0 
0 
0 
0 
0 
0 
0 
0 


图 8-15 


接 下 来 滚动 更 新 应 用 ， 配 置 文件 app.v2.yml， 如 图 8-16 所 示 。 


apiVersion: apps/vibetal 
kind: Deployment 


containers: 

- name: app 
image: busybox 
args: 

- /bin/sh 


- -Ç 
readinessProbe: 
exec: 


command: 
- cat 


- /tmp/healthy 
initialDelaySeconds: 
periodSeconds: 


图 8-16 


很 显然 
探测 的 ， 验 证 如 图 8-17 所 示 。 


然 ， 由 于 新 副本 中 不 存在 /tmp/healthy， 因 此 是 无 法 通 


过 Readiness 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl apply -f app.v2.yml --record 
deployment "app" configured 

ubuntu@k8s-master: ~$ 

ubuntu@k8s-master:~$ kubectl get deployment app 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
app 10 13 5 8 5m 
ubuntu@k8s-master :~ 

ubuntu@k8s-master:~$ kubectl get pod 

NAME READY STATUS RESTARTS AGE 
app-2780995820-Ompfl 1/1 Running 5m 
app-2780995820-g@srs 1/1 Running 5m 
app-2780995820-g52wp 1/1 Running 5m 
app-2780995820-kddms 1/1 Running 5m 
app-2780995820-rrwsh 1/1 Running 5m 
app-2780995820-t3k14 1/1 Running 5m 
app-2780995820-viqzn 1/1 Running 5m 
app-2780995820-z8qx4 1/1 Running 5m 
app-3350497563-d31s3 0/1 Running 49s 
app-3350497563-fkjvq 0/1 Running 49s 
app-3350497563-1tjp3 0/1 Running 49s 
app-3350497563-qm92c ”0/1 Running 49s 
app-3350497563-vh56z 0/1 Running 
ubuntuék8s -master : ~$ 


[S ME ME ME ME ME E ME ME E M ME E 


18-17 
这 个 截图 包含 了 大 量 的 信息 ， 值 得 我 们 详细 分 析 。 
先 关 注 kubectl get pod 输 出 : 


(1) 从 Pod 的 AGE 栏 可 判断 ， 最 后 5 个 Pod 是 新 副本 ， 目 前 处 于 NOT 
READY 状 态 。 


(2) 旧 副 本 从 最 初 10 个 减少 到 8 个 。 
再 来 看 kubectl get deployment app 的 输出 : 
1) DESIRED 10 表 示 期 望 的 状态 是 10 个 READY 的 副本 。 
2) CURRENT 13 表 示 当 前 副本 的 总 数 ， 即 8 个 旧 副 本 +5 个 新 副本 。 


( 
( 
2 UP-TO-DATE 5 表示 当前 已 经 完成 更 新 的 副本 数 ， 即 5 个 新 副 


(4) AVAILABLE 8 表示 当前 处 于 READY 状 态 的 副本 数 ， 即 8 个 旧 副 


在 我 们 的 设 定 中 ， 新 副本 始终 都 无 法 通过 Readiness 探 测 ， 所 以 这 个 状 
ies o PA ® 


上 面 我 们 模拟 了 一 个 滚动 更 新 失败 的 场景 。 不 过 亚运 的 是 : Health 
Check 硕 我 们 屏蔽 了 有 缺陷 的 副本 ， 同 时 保留 了 大 部 分 旧 副 本 ， 业 务 
没有 因 更 新 失败 受到 影响 。 

uar EOM 为 什么 新 创建 的 副本 数 是 5 个 ， 同 时 只 销毁 了 2 个 
旧 副 本 ? 


原因 是 : 滚动 更 新 通过 参数 maxSurge 和 maxUnavailable 来 控制 副本 替 
换 的 数量 。 


1. maxSurge 


此 参数 控制 滚动 更 新 过 程 中 副本 总 数 超过 DESIRED 的 上 限 。maxSurge 
可 以 是 具体 的 整数 (比如 3) ， 也 可 以 是 百 分 百 ， 向 上 取 整 。 
maxSurge 默 认 值 为 2526。 


在 上 面 的 例子 中 ，DESIRED 为 10， 那 么 副本 总 数 的 最 大 值 为 
roundUp(10 + 10 * 25%) =13， 所 以 我 们 看 到 CURRENT 就 是 13。 


2. maxUnavailable 


此 参数 控制 滚动 更 新 过 程 中 ， 不 可 用 的 副本 相 占 DESIRED 的 最 大 比 
例 。maxUnavailable 可 以 是 具体 的 整数 (比如 3) ， 也 可 以 是 百 分 百 ， 
回 下 取 整 。maxUnavailable 默 认 值 为 2526。 


在 上 面 的 例子 中 ，DESIRED 为 10， 那 么 可 用 的 副本 数 至 少 要 为 10 - 
roundDown(10 * 2526)- 8， 所 以 我 们 看 到 AVAILABLE 是 8。 


maxSurge 值 越 大 ， 初 始 创建 的 新 副本 数量 就 越 多 ; maxUnavailable 值 
越 大 ， 初 始 销毁 的 旧 副 本 数量 就 越 多 。 


理想 情况 下 ， 我 们 这 个 案例 深 动 更 新 的 过 程 应 该 是 这 样 的 : 


(1) 创建 3 个 新 副本 使 副本 总 数 达 到 13 个 。 

(2) 销毁 2 个 旧 副 本 使 可 用 的 副本 数 降 到 8 个 。 

(3) 当 2 个 旧 副 本 成 功 销毁 后 ， 再 创建 2 个 新 副本 ， 使 副本 总 数 保 持 为 
13 个 。 (4) 当 新 副本 通过 Readiness 探 测 后 ， 会 使 可 用 副本 数 增加 ， 
超过 8。 

(5) 进而 可 以 继续 销毁 更 多 的 旧 副 本 ， 使 可 用 副本 数 回 到 8 © 


(6) 旧 副 本 的 销毁 使 副本 总 数 低 于 13， 这 样 就 允许 创建 更 多 的 新 副 


(7) 这 个 过 程 会 持续 进行 ， 最 终 所 有 的 旧 副 本 都 会 被 新 副本 替换 ， 滚 
动 更 新 完成 。 
而 我 们 的 实际 情况 是 在 第 4 步 束 卡 住 了 ， 痢 副本 无 法 通过 Readiness 探 


测 。 这 个 过 程 可 以 在 kubectl describe deployment app 的 日 志 部 分 查看 ， 
如 图 8-18 所 示 ° 


Reason Message 


Normal ScalingReplicaSet Scaled up replica set app-2780995820 to 10 
Normal ScalingReplicaSet Scaled up replica set app-3350497563 to 3 
Normal ScalingReplicaSet Scaled down replica set app-2780995820 to 8 


Normal ScalingReplicaSet Scaled up replica set app-3350497563 to 5 


图 8-18 


如 果 滚 动 更 新 失败 ， 可 以 通过 kubectl rollout undo 回 湾 到 上 一 个 版 本 ， 
如 图 8-19 所 示 ° 


ubuntu@k&s-master : ~$ 
ubuntuék8s-master:-$ kubectl rollout history deployment app 
deployments "app 


" 


REVISION CHANGE-CAUSE 
1 kubectl apply --filename=app.vi.yml --record=true 
2 kubectl apply --filename=app.v2.yml --record=true 


ubuntu@k8s-master :~ 

ubuntuék8s-master:-$ kubectl rollout undo deployment app --to-revision=1 
deployment "app" rolled back 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get deployment app 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
app 10 10 10 10 1h 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod 

NAME READY STATUS RESTARTS AGE 
app-2780995820-Ompfl 1/1 Running 1h 
app-2780995820-bq3zd 1/1 Running 1m 
app-2780995820-g0srs 1/1 Running 1h 
app-2780995820-g52wp 1/1 Running 1h 
app-2780995820-kddms 1/1 Running 1h 
app-2780995820-m@cvr 1/1 Running 1m 
app-2780995820-rrwsh 1/1 Running ih 
app-2780995820-t3kl4 1/1 Running 1h 
app-2780995820-viqzn 1/1 Running 1h 
app-2780995820-z8qx4 1/1 Running 1h 
ubuntuék8s -master :~ 


esooooooo MESS] 


图 8-19 


如 果 要 定制 maxSurge 和 maxUnavailable， 可 以 进行 如 图 8-20 所 示 的 配 
置 o 


apiVersion: apps/vibetal 
kind: Deployment 


replicas: 
template: 
metadata: 


containers: 
- name: app 
image: busybox 
args: 
- /bin/sh 
- -C 
- sleep 
readinessProbe: 
exec: 
command : 
- cat 
- /tmp/healthy 
initialDelaySeconds : 
periodSeconds: 


图 8-20 


8.6 ”小 结 


本 章 我 们 讨论 了 Kubernetes 健 康 检 查 的 两 种 机 制 : Liveness 探 测 和 
Readiness 探 测 ， 并 实践 了 健康 检查 在 Scale Up 和 Rolling Update 场 景 中 


的 应 用 。 
Poe ”数据 管理 


本 章 将 讨论 Kubernetes 如 何 管理 存储 资源 。 


首先 我 们 会 学 习 Volume， 以 及 Kubernetes 如 何 通 过 Volume 为 集群 中 的 
容器 提供 存储 ;然后 我 们 会 实践 几 种 常用 的 Volume 类 型 并 理解 它们 各 
目的 应 用 场景 ;， 最后， 我 们 会 讨论 Kubernetes 如 何 通 过 Persistent 
Volume 和 Persistent Volume Claim 分 离 集群 管理 员 与 集群 用 户 的 职 贡 ， 
并 实践 Volume 的 静态 供给 和 动态 供给 。 


9.1 Volume 


AN“ El ie Kubernetes Hy T£ fif 7 Volume, 2 >) UATE PPS AK 
存储 映射 到 容器 。 


我 们 经 常会 说 : 容 锅 和 Pod 是 短暂 的 。 其 含义 是 它们 的 生命 周期 可 能 
很 短 ， 会 被 频 和 党 地 销毁 和 创建 。 容 闫 销毁 时 ， 保 存在 容 船 内 部 文件 系 
统 中 的 数据 都 会 被 清除 。 


为 了 持久 化 保存 容器 的 数据 ， 可 以 使 用 Kubernetes Volume ° 
Volume 的 生命 周期 独立 于 容器 ，Pod 中 的 容器 可 能 被 销毁 和 重建 ， 但 


Volume 会 被 保留 。 


本 质 上 ，Kubernetes Volumezé — T H 3€, 3X — 4 5 Docker Volume% 
IL] » 4 Volume fX mount 2!) Pod, Pod ¥ ay Pr/& 4 ss db n] DA S IR] 3x A 
Volume ° Kubernetes Volume 也 文 持 多 种 backend 类 型 ， 包 括 emptyDir、 

hostPath ^ GCE Persistent Disk ` AWS Elastic Block Store ` NFS ` Ceph 
等 完 整 列 表 可 参 学 


https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes ° 


Volume 提 供 了 对 各 种 backend 的 抽象 ， 容 絮 在 使 用 Volume 读 写 数 据 的 时 
TRAN Fe BK OD AGE Bl Re EE AS RUE A EA PIR ED IA 
上 。 对 它 来 说 ， 所 有 类 型 的 Volume 都 只 是 一 个 日 录 。 


我 们 将 从 最 人 简单 的 emptyDir 开 始 学 习 Kubernetes Volume ° 


9.1.1 emptyDir 


emptyDir 是 最 基础 的 Volume 类 型 。 正 如 其 名 字 所 示 ， 一 个 emptyDir 
Volume 是 Host 上 的 一 个 空 目录 。 


emptyDir Volume 对 于 容器 来 说 是 持久 的 ， 对 于 Pod 则 不 是 。 当 Pod 从 贡 
扩 删 除 时 ，Volume 的 内 容 也 会 被 删除 。 但 如 琳 只 是 容 胡 被 销 虹 而 Pod 
还 在 ， 则 Volume 不 受 影 响 。 


也 就 是 说 : emptyDir Volume 的 生命 周期 与 Pod 一 致 。 


Pod 中 的 所 有 容器 都 可 以 共享 Volume， 它 们 可 以 指定 各 自 的 mount 路 
径 。 下 面 通过 例子 来 实践 emptyDir， 配 置 文件 如 图 9-1 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 
name: producer-consumer 
spec: 
containers: 
- image: busybox 
name: producer 
voLumeMounts: 
- mountPath: /producer dir (2 
name: shared-volume 
args: 
- /bin/sh 
= =C 


- echo > /producer_dir/hello ; sleep 


- image: busybox 
name: consumer 
voLumeMounts: 
- mountPath: /consumer_dir 
name: shared-volume 
args: 
- /bin/sh 
- -C 
- cat /consumer_dir/hello ; sleep 


volumes: 
- name: shared-volume 
emptyDir: {} 


图 9-1 


这 里 我 们 模拟 了 一 个 producer-consumer 场 景 。Pod 有 两 个 容 避 producer 
和 consumer， 它 们 共享 一 个 Volume ° producer ffi T ft Volume "P & BY 
据 ，consumer 则 是 从 Volume 读 取 数 据 。 


D 文件 最 底部 volumes 定 义 了 一 个 emptyDir 类 型 的 Volume shared- 
volume ° 


ELE y 


Q producer 容 器 将 shared-volume mount#!]/producer_dir H 3& ° 


© producer 通 过 echo 将 数据 写 到 文件 hello 里 。 


AX HE 


@ consumer 23 Ff shared-volume mount!) /consumer_dir H 5X ° 


@ consumer 通 过 cat 从 文件 hello 读 数据 。 
执行 命令 创建 Pod， 如 图 9-2 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl apply -f emptyDir.yml 


pod "producer-consumer" created 
ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get pod 


NAME READY STATUS RESTARTS AGE 
producer-consumer 2/2 Running 0 15s 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl logs producer-consumer consumer 
hello world 


图 9-2 


kubectl logs m 容器 consumer 成 功 读 到 了 producer 写 入 的 数据 ， 验 证 了 
两 个 容器 共享 emptyDir Volume ° 


因为 emptyDir 是 Docker Host 文 件 系 统 里 的 目录 ， 其 效果 相当 于 执行 


docker run -v/producer_dir 和 docker run -v /consumer_dir ° las 
inspect AARAA EL E, Dell ACER T Ege b mount 了 同一 个 
目录 ， 如 图 9-3、 图 9-4 所 示 » 


"mounts": [ 
{ 
"Source": "/var/lib/kubelet/pods/3e6100eb-a97a-11e7-8f72-080027 
4451ad/volumes/kubernetes.io-empty-dir/shared-volume", 
"Destination": "/producer_dir", 
"Mode": "", 
"RW": true, 
"Propagation": "rprivate" 


h 


图 9-3 


"mounts": [ 
{ 
"Source": "/var/lib/kubelet/pods/3e6100eb-a97a-11e7-8f72-080027 
4451ad/volumes/kubernetes .io~empty-dir/shared-volume" , 
"Destination": "/consumer. dir", 
"Mode": "", 
"RW": true, 
"Propagation": "rprivate" 


}, 


图 9-4 


这 里 /var/lib/kubelet/pods/3e6100eb-a97a-11e7-8f72- 


0800274451ad/volumes/kubernetes. io ~ empty-dir/shared-volume 就 是 
emptyDir 在 Host 上 的 真正 路 径 。 


emptyDir 是 Host 上 创建 的 临时 目录 ， 其 优点 是 能 够 方便 地 为 Pod 中 的 容 

铬 提供 共 圣 存储 ， 不 需要 额外 的 配置 。 它 不 具备 持久 性 ， 如 果 Pod 不 

存在 了 ，emptyDir 也 就 没有 了 。 根 据 这 个 特性 ，emptyDir 特 别 适 合 Pod 

E 比如 前 面 的 生产 者 消费 者 用 
l| o 


9.1.2 hostPath 


hostPath Volume I^] fE Fl Æ f Docker Host 文 件 系统 中 已 经 存在 的 目录 

mount 给 Pod 的 容 妖 。 大 部 分 应 用 都 不 会 使 用 hostPath Volume， 因 为 这 

实际 上 增加 了 Pod 与 世上 点 的 耦合 ， 限 制 了 Pod 的 使 用 。 不 过 那些 需要 访 

Nu EERR (配置 文件 和 二 进 制 库 ) 的 应 用 则 需要 
hostPath ° 


FE 4 kube-apiserver 41] kube-controller-manager Wi ze ix FEA DY Hj, 3B 
kubectl edit--namespace-kube-system pod kube-apiserver-k8s-master Æ 
kube-apiserver Pod 的 配置 ，Volume 的 相关 部 分 如 图 9-5 所 示 。 


证 
看 


voLumeMounts: 
- mountPath: /etc/kubernetes 
name: k8s 
readOnly: 
- mountPath: /etc/ssl/certs 
name: certs 
- mountPath: /etc/pki 
name: pki 
dnsPolicy: ClusterFirst 
hostNetwork: 
nodeName: k&s-master 
restartPolicy: Always 
schedulerName: default-scheduler 
securityContext: {} 
terminationGracePeriodSeconds: 
tolerations: 
- effect: NoExecute 
operator: Exists 
volumes: 
- hostPath: 
path: /etc/kubernetes 
name: k&s 
hostPath: 
path: /etc/ssl/certs 
name: certs 
- hostPath: 
path: /etc/pki 
name: pki 


图 9-5 


这 里 定义 了 三 个 hostPath: volume k8s、certs 和 pki， 分 别 对 应 Host 目 
孙 /etc/kubernetes、/etc/sslcerts 和 /etc/pki。 


如 条 Pod 被 销毁 了，hostPath 对 应 的 目录 还 是 会 被 保留 ， 从 这 一 点 来 
看 ，hostPath 的 持久 性 比 emptyDir 强 。 不 过 一 旦 Host 表 种 ，hostPath 也 
束 无 法 访问 了 。 


接 下 来 我 们 将 学 习 具 备 真正 持久 性 的 Volume ° 
9.1.3 ”外 部 Storage Provider 
如 果 Kubemetes 部 署 在 诸如 AWS、GCE、Azure 等 公有 云 上 ， 可 以 直接 


使 用 云 硬 盘 作 为 Volume。 下 面 给 出 一 个 AWS Elastic Block Store 的 例 
子 ， 如 图 9-6 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 

name: using-ebs 

spec: 

containers: 

- image: busybox 
name: using-ebs 
volumeMounts: 

- mountPath: /test-ebs 
name: ebs-volume 
volumes: 

- name: ebs-volume 


awsElasticBlockStore: 
volumeID: <volume-id> 
fsType: ext4 


图 9-6 


要 在 Pod 中 使 用 ESB volume， 必 须 先 在 AWS 中 创建 ， 然 后 通过 volume- 
id 引用 。 其 他 云 便 盘 的 使 用 方法 可 参考 各 公有 云 厂商 的 官方 文档 。 


Kubernetes Volume 也 可 以 使 用 主流 的 分 布 式 存 储 ， 比 如 Ceph、 
GlusterFS 等 。 下 面 给 出 一 个 Ceph 的 例子 ， 如 图 9-7 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 
name: using-ceph 
spec: 
containers: 
- image: busybox 
name: using-ceph 
voLumeMounts: 
- name: ceph-volume 
mountPath: /test-ceph 
volumes: 
- name: ceph-volume 
cephfs: 
path: /some/path/in/side/cephfs 
monitors: 
secretFile: 


图 9-7 


Ceph X £F 2 2 H4/some/path/in/side/cephfs H >< #¥mount l| 4 as FS 12 /test- 
ceph ° 


THX FemptyDir#lhostPath, i £6 Volume X 78 WY Be RE 53, Bb des A RN 
Kubemetes ° Volume fJ JI£ E 基础 设施 由 独立 的 存储 系统 管理 ， 与 
Kubernetes 集 集群 是 分 离 的 。 数 据 被 持久 化 后 ， 即 使 Bt /* Kubernetes ff int 
也 不 会 受 损 。 


当然 ， 运 维 这 样 的 存储 系统 通常 不 是 一 项 简单 的 工作 ， 特 别 是 对 可 靠 
性 、 可 用 性 和 扩展 性 有 较 高 要 求 的 时 候 。 


9.2 Persistent Volume & 
PersistentVolumeClaim 


aa 了 非常 好 的 数据 持久 化 方案 ， 不 过 在 可 管理 性 上 还 有 不 


EBS 例 子 来 说 ， 要 使 用 Volume，Pod 必 须 事 先知 道 如 下 


(1) 当前 Volume 来 自 AWS EBS 。 
(2) EBS Volume 已 经 提前 创建 ， 并 且 知 道 确 切 的 volume-id ° 


Pod 通 利 是 由 应 用 的 开发 人 员 维 护 ， 征 由 存储 系统 的 
管理 员 维护 。 开 发 人 员 要 获得 上 面 的 信息 ， 要 么 询问 管理 员 ， 要 人 么 目 
CPEB ERE o 
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合 在 一 起 了 。 如 采 系 统 规模 较 小 或 者 对 于 开发 环境 ， 这 样 的 情况 还 可 
以 接受 ， 当 集群 规模 变 大 ， 特 别 是 对 于 生成 环境 ， 考 虑 到 效率 和 安全 
性 ， 这 就 成 了 必须 要 解决 的 问题 。 


Kubemetes 给 出 的 解决 方案 是 PersistentVolume 和 
PersistentVolumeClaim ° 


PersistentVolume (PV) 是 外 部 存储 系统 中 的 一 块 存储 空间 ， 由 管理 员 
创建 和 维护 。 与 Volume 一 样 ，PV 具 有 持久 性 ， 生 命 周 期 独立 于 Pod 。 


PersistentVolumeClaim (PVC) 是 对 PV 的 申请 (Claim) 。PVC 通 常 由 
普通 用 户 创建 和 维护 。 需 要 为 Pod 分 配 存 储 资 源 时 ， 用 户 可 以 创建 一 
个 PVC， 指 明 存 储 资 源 的 容量 大 小 和 访问 模式 (比如 只 读 ) 等 信息 ， 
Kubernetes 会 查找 并 提供 满足 条 件 的 PV。 


有 了 PersistentVolumeClaim ， 用 户 只 需要 告诉 Kubernetes 需 要 什么 样 的 
存储 资源 ， 而 不 必 天 心 真正 的 空间 从 哪里 分 配 、 如 何 访问 等 底层 细节 
信息 。 这 些 Storage Provider 的 确 层 信息 交 给 管理 员 来 处 理 ， 只 有 管理 
员 才 应 该 关心 创建 PersistentVolume 的 细节 信 息 。 


Kubernetes 文 持 多 种 类 型 的 PersistentVolume ， 比 如 AWS EBS ` Ceph ` 
NFS 等 | x 整 JI HR 请 B 
https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of- 
persistent-volumes ° 


下 面 我 们 用 NFS 来 体会 PersistentVolume 的 使 用 方法 ° 


9.2.1 NES PersistentVolume 


作为 准备 工作 ， 我 们 已 经 在 k8s-master 节 点 上 搭建 了 一 个 NFS 服 务 器 ， 
日 如 为 /nfsdata， 如 图 9-8 所 示 。 


root@k8s-master :~# 
root@k8s-master:~# showmount -e 


Export list for k8s-master: 
/nfsdata * 


图 9-8 


下 面 创 建 一 个 PV mypv1， 配 置 文件 nfs-pv1.yml 如 图 9-9 所 示 。 


apiVersion: v1 
kind: PersistentVoLume 
metadata: 
name: mypv1 
spec: 
capacity: 
storage: 1Gi 


accessModes: 

- ReadWriteOnce 
persistentVolumeReclaimPolicy: Recycle 
storageClassName: nfs 
nfs: 

path: /nfsdata/pv1 

server: 192.168.56.105 


图 9-9 
(D capacity 指 定 PV 的 容量 为 1GB ° 


@ accessModes 指 定 访问 模式 为 ReadWriteOnce , 支持 的 访问 模式 有 3 
fi: ReadWriteOnce 3€ 7 7K PV 能 以 read-write 模 式 mount 到 单个 节点 ， 
ReadOnlyMany 表示 PV 能 以 read-only 模 式 mount 到 多 个 节点 ， 
ReadWriteMany 表 示 PV 能 以 read-write 模 式 mount 到 多 re 2 


@ persistent VolumeReclaimPolicy7R E 4 PV RS [RIA ERE Recycle, TF 
的 策略 有 3 种 : Retain 表 示 需 要 管理 员 手 工 回收 ; Recycle 表 示 清 除 PV 
中 的 数据 ， 效 果 相 当 于 执行 rm -rf/thevolume/*; Delete 表 示 删 除 Storage 
Provider 上 的 对 应 存储 资源 ， 例 如 AWS EBS ` GCE PD ` Azure Disk ^ 
OpenStack Cinder Volume 等 。 


@ storageClassName 指 定 PV 的 class 为 nfs。 相 当 于 为 PV 设置 了 一 个 分 
类 ，PVC 可 以 指定 class 申 请 相应 class 的 PY 。 


指定 PV 在 NFS 服 务 器 上 对 应 的 目录 。 
创建 mypv1， 如 图 9-10 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f nfs-pv1.yml 
persistentvolume "mypv1" created 
ubuntu@k8s-master: ~$ 


ubuntuék8s-master:-$ kubectl get pv 


NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON 
mypvi 1Gi RWO Recycle Available nfs 
ubuntu@k8s-master: ~$ 


19-10 
STATUS 为 Available， 表 示 mypv1 就 绪 ， 可 以 被 PVC 申 请 。 
接 下 来 创建 PVC mypvc1， 配 置 文件 nfs-pvcl.yml 如 图 9-11 所 示 。 


kind: PersistentVolumeClaim 
apiVersion: v1 
metadata: 
name: mypvci 
spec: 


accessModes: 
- ReadWriteOnce 
resources: 
requests: 
storage: 1Gi 
storageClassName: nfs 


图 9-11 
PVC 就 很 简单 了 ， 只 需要 指定 PV 的 容量 、 访 问 模式 和 class 即 可 。 


创建 mypvcl1， 如 图 9-12 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f nfs-pvc1.yml 
persistentvolumeclaim "mypvc1" created 
ubuntu@k8s-master : ~$ 


CAPACITY ACCESSMODES STORAGECLASS AGE 
1Gi RWO 22s 


ubuntu@k8s-master:~$ kubectl get pv 


CAPACITY ACCESSMODES RECLAIMPOLICY [STATUS CLAIM STORAGECLASS REASON AGE 
1Gi RWO Recycle Bound default/mypvc1} nfs 6m 


图 9-12 


从 kubectl get pvc 和 kubectl get pv 的 输出 可 以 看 到 mypvcl 已 经 Bound 到 
mypv1， 申 请 成 功 。 


接 下 来 束 可 以 在 Pod 中 使 用 存储 了 ，Pod 配 置 文 件 pod1.yml 如 图 9-13 所 
ZN œ 


kind: Pod 
apiVersion: v1 
metadata: 
name: mypod1 
spec: 
containers: 
- name: mypod1 
image: busybox 
args: 
- /bin/sh 
- -C 
- sleep 
volumeMounts : 
- mountPath: 
name: mydata 
volumes: 
- name: mydata 
persistentVolumeClaim: 
claimName: mypvci 


19-13 


5 f& Hj Xf o8 Volume Hy T& 5X 2S fH. Æ volumes 中 通过 
persistent VolumeClaim1R E (i FA mypvc1 HH iR, Volume ° 


创建 mypod1， 如 图 9-14 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f pod1.yml 

pod "mypodi" created 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE IP NODE 
mypod1 1/1 Running 0 32s 10.244.4.60 — k8s-node1 
ubuntuék8s master : ~$ 


图 9-14 


验证 PV 是 否 可 用 ， 如 图 9-15 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl exec mypod1 touch /mydata/hello 
ubuntu@k8s-master : ~$ 


ubuntu@k8s-master:~$ ls /nfsdata/pv1/ 
hello 
ubuntuek8s-master : ~$ 


图 9-15 


可 见 ， 在 Pod 中 创建 的 文件 /mydata/hello 确 实 已 经 保存 到 了 了 NFS 服务器 
目录 /nfsdata/pv1l 中 。 


9.2.2 ”回收 PV 
当 不 需要 使 用 PV 时 ， 可 用 删除 PVC 回 收 PY， 如 图 9-16 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl delete pvc mypvci 
persistentvolumeclaim "mypvci" deleted 
ubuntuék8s master: ~$ 
ubuntu@k8s-master:~$ kubectl get pod -o wide 
READY STATUS RESTARTS IP NODE 
1/1 Running 0 2 10.244.4.60 k&s-nodel 


p 
0/1 ContainerCreating 0 <none> k8s-node1 
ubuntu@k8s-master : ~$ 


ubuntu@k8s-master:~$ kubectl get pv 
NAME CAPACITY ACCESSMODES RECLAIMPOLICY | STATUS CLAIM STORAGECLASS REA 
mypvi 1Gi RWO Recycle Released} default/mypvci nfs 


ubuntu@k8s-master :~$ 


图 9-16 


当 PVC mypvcl 被 删除 后 ， 我 们 发 现 Kubemnetes 启 动 了 一 个 新 Pod 
recycler-formypv1， 这 个 Pod 的 作用 区 是 清除 PV mypv1 的 数据 。 此 时 
mypv1 的 状态 为 Released， 表 示 已 经 解除 了 与 mypvcl 的 Bound， 正 在 清 
除数 据 ， 不 过 此 时 还 不 可 用 。 


当 数 据 清除 完毕 ，mypv1 的 状态 重新 变 为 Available ， 此 时 可 以 被 新 的 
PVC 申 请 ， 如 图 9-17 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl get pv 


CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS 
1Gi RWO Recycle Available nfs 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ ls /nfsdata/pv1/ 
Dun @kSs-ma er .~ 


图 9-17 
/mnfsdata/pv1 中 的 hello 文 件 已 经 被 删除 了 ° 
因为 PV 的 回收 偶 上 略 设 置 为 Recycle， 所 以 数据 会 被 清除 ， 但 这 可 能 不 是 


我 们 想 要 的 结果 。 如 果 我 们 希望 保留 数据 ， 可 以 将 策略 设置 为 
Retain， 如 图 9-18 所 示 。 


apiVersion: v1 
kind: PersistentVoLume 
metadata: 
name: mypvi 
spec: 
capacity: 
storage: 1Gi 


accessModes: 
- ReadWriteOnce 


storageCLlassName: nfs 
nfs: 
path: /nfsdata/pv1 
server: 192.168.56.105 


图 9-18 


通过 kubectl apply 更 新 PY， 如 图 9-19 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f nfs-pv1.yml 
persistentvolume "mypvi" configured 

ubuntuek8s master: ~$ 

ubuntu@k8s-master:~$ kubectl get pv 


NAME CAPACITY | ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS 
mypvi 1Gi RWO Retain Available nfs 


ubuntuék8s master: ~$ 


图 9-19 


回收 策略 已 经 变 为 Retain， 通 过 下 面 的 步骤 验证 其 效果 ， 如 图 9-20 所 
ZN o 


ubuntuek8s master: ~$ 

ubuntu@k8s-master:~$ kubectl apply -f nfs-pvci.yml 
persistentvolumeclaim "mypvc1" created 

ubuntuék8s master: ~$ 

ubuntuék8s-master:-$ kubectl exec mypod1 touch /mydata/hello 
ubuntuék8s master: ~$ 

ubuntuék8s-master:-$ ls /nfsdata/pv1/ 

hello 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl delete pvc mypvci 
persistentvolumeclaim "mypvci" deleted 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pv 

NAME CAPACITY ACCESSMODES RECLAIMPOLICY STA STORAGECLASS 
Released 


mypv1 1Gi RWO Retain 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pod -o wide 
NAME READY STATUS RESTARTS AGE IP NODE 
mypod1 1/1 Running 0 46m 10.244.4.60 k8&s-node1 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ ls /nfsdata/pv1/ 

hello 

ubuntu@k8s-master : ~$ 


default/mypvc1l nfs 


图 9-20 
© 重新 创建 mypvcl。 
@ 在 mypv1 中 创建 文件 hello。 
© mypv1 状 态 变 为 Released ° 
@ Kubernetes 并 没有 局 动 Pod recycler-for-mypv1 ° 
© PV 中 的 数据 被 完整 保留 。 
然 mypv1 中 的 数据 得 到 了 保留 ， 但 其 PV 状态 会 一 直 处 于 Released， 
能 被 其 他 PVC 申 请 。 为 了 重新 使 用 存储 资源 ， 可 以 删除 并 重新 创建 
mo 删除 操作 只 是 删除 了 PV 对 象 ， 存 储 空间 中 的 数据 并 不 会 被 删 
新 建 的 mypv1 状 态 为 Available， 如 图 9-21 所 示 ， 已 经 可 以 被 PVC 申 请 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl delete pv mypv1 
persistentvolume "mypv1" deleted 
ubuntu@k8s-master: ~$ 

has ntu @k8s-master: ~$ b ipe apply -f nfs-pvi.yml 


lume "mypvi" created 
KA intu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get 


NAME SES ACCESSMODES " RECLATHPOLICI STATUS CLAIM STORAGECLASS REASON AGE 
mypv1 1Gi RWO Retai Available nfs 9s 


ubuntu@k8s-master:~$ 


图 9-21 


PV 还 文 持 Delete 的 回收 策略 ， 会 删除 PV 在 Storage Provider 上 对 应 的 存 
储 空间 。NFS 的 PV 不 支持 Delete， 支 持 Delete 的 Provider 有 AWS EBS ` 
GCE PD ^ Azure Disk ` OpenStack Cinder Volume 等 。 


9.2.3 ”PV 动态 供给 


在 前 面 的 例子 中 ， 我 们 提前 创建 了 PV， 然 后 通过 PVC 申 请 PV 并 在 Pod 
中 使 用 ， 这 种 方式 叫 作 静态 供给 (Static Provision) ° 


与 之 对 应 的 是 动态 供给 (Dynamical Provision) ， 即 如 果 没 有 满足 PVC 
条 件 的 PV， 会 动态 创建 PV。 相 比 静态 供给 ， 动 态 供给 有 明显 的 优 


势 : 不 需 要 提前 创建 PV， 减少 了 管理 员 的 工作 量 ， 效 率 高 。 


动态 供给 是 通过 StorageClass 实 现 的 ，StorageClass 定 义 了 如 何 创建 
PV， 下 面 给 出 两 个 例子 。 


(1) StorageClass standard， 如 图 9-22 所 示 。 


kind: StorageClass 
apiVersion: storage.k8s.io/v1 
metadata: 

name: standard 


provisioner: kubernetes.io/aws-ebs 
parameters: 

type: gp2 
reclaimPolicy: Retain 


图 9-22 


(2) StorageClass slow， 如 图 9-23 所 示 。 


kind: StorageClass 
apiVersion: storage.k8s.io/v1 
metadata: 

name: slow 


provisioner: kubernetes.10/aws-ebs 
parameters: 
type: io1 
zones: us-east-1d, us-east-1c 
iopsPerGB: 


图 9-23 
这 两 个 StorageClass 都 会 动态 创建 AWS EBS， 不 同 点 在 于 standard 创 建 
的 是 gp2 类 型 的 EBS， 而 slow 创 建 的 是 io1 类 型 的 EBS。 不 同类 型 的 EBS 
文 持 的 参数 可 参考 AWS 官 方 文档 。 


StorageClass 文 持 Delete 和 Retain 两 种 reclaimPolicy， 默 认 是 Delete ° 


福 之 前 一 样 ，PVC 在 申请 PV 时 ， 只 需要 指定 StorageClass、 容 量 以 及 访 
问 模 式 即 可 ， 如 图 9-24 所 示 。 


kind: PersistentVolumeClaim 
apiVersion: v1 
metadata: 

name: mypvci 


spec: 


accessModes: 
- ReadWriteOnce 
resources: 
requests: 
storage: 1Gi 
图 9-24 
除了 AWS EBS ，Kubernetes 还 文 持 其 他 多 种 动态 供给 PV 的 
Provisioner 完 整 列 表 请 参 E 


https://kubernetes.io/docs/concepts/storage/storage-classes/#provisioner ° 


9.3 “一 个 数据 库 例 子 


本 市 演示 如 何 为 MySQL 数 据 库 提 供 持久 化 存储 ， 步 又 为 : 


(1) 创建 PV 和 PVC。 

(2) 部 署 MySQL 。 

(3) 向 MySQL 添 加 数据 。 

(4) 模拟 节点 宕 机 故障 ，Kubernetes 将 MySQL 自 动迁 移 到 其 他 节点 。 


(5) 验证 数据 一 致 性 。 
首先 创建 PV 和 PVC， 配 置 说 明 如 下 。 


。 mysql-pv.yml 如 图 9-25 所 示 。 


apiVersion: v1 
kind: PersistentVolume 
metadata: 
name: mysql-pv 
spec: 
accessModes: 
- ReadWriteOnce 


capacity: 

storage: 1Gi 
persistentVolumeReclaimPolicy: Retain 
storageCLassName: nfs 
nfs: 

path: /nfsdata/mysql-pv 

server: 192.168.56.105 


图 9-25 
。 mysql-pvc.yml 如 图 9-26 所 示 。 


kind: PersistentVolumeClaim 
apiVersion: v1 
metadata: 
name: mysql-pvc 
spec: 
accessModes: 


- ReadWriteOnce 


resources: 
requests: 
storage: 1Gi 
storageCLlassName: nfs 


图 9-26 


创建 mysql-pv 和 mysql-pvc， 如 图 9-27 所 示 。 


ubuntu@k8s-master: ~$ 

ubuntuék8s-master:-$ kubectl apply -f mysql-pv.yml 
persistentvolume "mysql-pv" created 
ubuntuék8s-master: ~$ 

ubuntuék8s-master:-$ kubectl apply -f mysql-pvc.yml 
persistentvolumeclaim "mysql-pvc" created 
ubuntu@k8s-master: ~$ 


ubuntu@k8s-master:~$ kubectl get pv,pvc 
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM 
pv/mysql-pv 1Gi RWO Retain Bound default/mysql-pvc 


NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE 
pvc/mysql-pvc Bound mysql-pv 1Gi RWO nfs 9s 
ubuntu@k8s-master:~$ 


图 9-27 


接 下 来 部 署 MySQL， 配 置 文 件 如 图 9-28 所 示 。 


apiVersion: v1 
kind: Service 
metadata: 
name: mysql 
spec: 
ports: 
- port: 
selector: 
app: mysql 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 
name: mysql 
spec: 
selector: 
matchLabels: 
app: mysql 
template: 
metadata: 
Labels: 
app: mysql 
spec: 
containers: 
- image: mysql:5.6 
name: mysql 
env: 
- name: MYSQL. ROOT. PASSWORD 
value: password 
ports: 
- containerPort: 
name: mysql 
voLumeMounts: 
- name: mysql-persistent-storage 
mountPath: /var/lib/mysql 
volumes: 
- name: mysql-persistent-storage 
persistentVolumeClaim: 
claimName: mysql-pvc 


图 9-28 


PVC mysql-pvc Bound 的 PV mysql-pv Ff $£ mount £l] MySQL B5 Zi js H K 
var/lib/mysql， 如 图 9-29 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl apply -f mysql.yml 
service "mysql" created 

deployment "mysql" created 


ubuntuék8s master : ~$ 

ubuntuék8s-master:-$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS AGE IP NODE 
mysql-2150355289-p99h8 1/1 Running 0 15s 10.244.5.80 — k8s-node2 
ubuntu@k8s-master : ~$ 


图 9-29 


MySQL 被 部 署 到 k8s-node2， 下 面 通过 客户 端 访 问 Service mysql, Anf 
9-30 所 示 。 


kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql- 
client -- mysql-h mysql -ppassword 


ubuntuék8s-master:-$ 
ubuntu@k8s-master:~$ kubectl run -it --rm --image-mysql:5.6 --restart-Never mysql-client -- mysql -h mysql -ppassword 


If you don't see a command prompt, try pressing enter. 


图 9-30 


更 新 数据 库 ， 如 图 9-31 所 示 。 


mysql> 

mysql> use mysql (1 

Reading table information for completion of table and column names 
You can turn off this feature to get a quicker startup with -A 


Database changed 
mysql> create table my id( id int(4) ); 
Query OK, 0 rows affected (0.01 sec) 


mysql> insert my id values( 111 ); 
Query OK, 1 row affected (0.00 sec) 


mysql> select * from my_id; 


1 row in set (0.00 sec) 


mysql» 


图 9-31 
@ 切换 到 数据 库 mysql » 
Q 创建 数据 库 表 my _id。 


@ 插入 一 条 数据 。 
@ 确认 数据 已 经 写 入 。 
关闭 k8s-node2， 模 拟 节 点 宕 机 故障 ， 如 图 9-32 所 示 。 


root@k8s-node2 :~# 
root@k8s-node2:~# shutdown now 


Connection to 192.168.56.107 closed by remote host. 
Connection to 192.168.56.107 closed. 


图 9-32 


一 段 时 间 后 ，Kubermetes 将 MySQL 迁 移 到 k8s-node1， 如 图 9-33 所 示 。 


s-master:-$ kubectl get pod -o wide 
NAME READY STATUS RESTARTS AGE IP NODE 
mysql-2150355289-p13n5 1/1 Running 10.244.4.66 — k8s-nodei 
mysql-2150355289-p99h8 TE Unknown 10.244.5.80 — k8s-node2 
ubuntu@k8s-master : ~$ 


图 9-33 


验证 数据 的 一 致 性 ， 如 图 9-34 所 示 。 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ kubectl run -it --rm --image-mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword 
If you don't see a command prompt, try pressing enter. 


mysql> use mysql 
Reading table information for completion of table and column names 
You can turn off this feature to get a quicker startup with -A 


Database changed 


mysql> select * from my_id; 


r in set (0.00 sec) 


图 9-34 


MySQL 服 务 恢复 ， 数 据 也 完好 无 损 。 
9.4 ”小结 


本 章 我 们 讨论 了 Kubernetes 如 何 管理 存储 资源 。 


emptyDir 和 hostPath 类 型 的 Volume 很 方便 ， 但 可 持久 性 不 强 ， 
Kubernetes 文 持 多 种 外 部 存储 系统 的 Volume ° 


PV 和 PVC 分 离 了 管理 员 和 普通 用 户 的 职责 ， 更 适合 生产 环境 。 我 们 还 
学 习 了 如 何 通过 StorageClass 实 现 更 高 效 的 动态 供给 。 


， 我 们 演示 了 如 何在 MySQL 中 使 用 PersistentVolume 实 现 数据 持久 
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应 用 局 动 过 程 中 可 能 需要 些 敏 感 信息 ， 比如 访问 数据 库 的 用 户 名 s 
ur p Be ER REAR RREEA BRR CB mA E, 
Kubemetes 提 供 的 解决 方案 是 Secret 。 

Secret 会 以 密 文 的 方式 存储 数据 ， 避 免 了 直接 在 配置 文件 中 保存 敏感 信 
已 。Secret 会 以 Volume 的 形式 被 mount 到 Pod， 容 器 可 通过 文件 的 方式 
使 用 Secret 中 的 敏感 数据 ， 此外， 容 絮 也 可 以 环境 变量 的 方式 使 用 这 些 
数据 。 

Secret 可 通过 命令 行 或 YAML 创 建 。 比 如 希望 Secret 中 包含 如 下 信息 : 
用 户 名 admin、 密 码 123456。 


10.1 创建 Secret 
有 四 种 方法 创建 Secret: 


(1) 通过 --from-literal: 


kubectl create secret generic mysecret --from- 
literal=username=admin --from-literal=password=123456 


每 个 --from-literal 对 应 一 个 信息 条 目 。 


(2) 通过 --from-file: 


echo -n admin > ./username 
echo -n 123456 > ./password 


kubectl create secret generic mysecret --from-file=./username - 
-from-file-./password 


每 个 文件 内 容 对 应 一 个 信息 条 目 。 
(3) 通过 --from-env-file: 
cat << EOF > env.txt 
username=admin 
password=123456 
EOF 


kubectl create secret generic mysecret --from-env- 
file=env.txt 


文件 env.txt 中 每 行 Key=Value 对 应 一 个 信息 条 目 。 
(4) 通过 YAML 配 置 文件 ， 如 图 10-1 所 示 。 


apiVersion: v1 
kind: Secret 
metadata: 

name: mysecret 
data: 

username: YWRtaW4= 


password: MTIzNDU2 


图 10-1 


文件 中 的 敏感 数据 必须 是 通过 base64 编 码 后 的 结果 ， 如 图 10-2 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ echo -n admin | base64 
YWRtaW4= 


ubuntu@k8s-master:~$ echo -n 123456 | base64 
MTIzNDU2 
ubuntu@k8s-master: ~$ 


图 10-2 


执行 kubectl apply 创 建 Secret， 如 图 10-3 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ kubectl apply -f mysecrete.yml 


secret "mysecret" created 
ubuntu@k8s-master : ~$ 


图 10-3 


10.2 ”查看 Secret 


通过 kubectl get secret 查 看 存在 的 secret， 如 图 10-4 所 示 。 


ubuntu@k8s-master: -$ kubectl get secret mysecret 


TYPE DATA AGE 
Opaque 2 4m 


ubuntu@k8s-master:~$ 


图 10-4 


显示 有 两 个 数据 条 有 日， 通过 kubectl describe secret 查 看 条 目的 Key， 如 
图 10-5 所 示 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl describe secret mysecret 
Name: mysecret 

Namespace: default 

Labels: <none> 

Annotations: <none> 


图 10-5 


如 果 还 想 查 看 Value， 可 以 用 kubectl edit secret mysecret, ， 如 图 10-6 所 
ZN o 


apiVersion: v1 
data: 
password: MTIzNDU2 
username: YWRtaW4= 
kind: Secret 
metadata: 
creationTimestamp: 2017-10-10T07:16:21Z 


name: mysecret 
namespace: default 
resourceVersion: 
selfLink: /api/v1/namespaces/default/secrets/mysecret 
uid: eaeb4980-ad8a-11e7-8f72-0800274451ad 
type: 0paque 


图 10-6 


然后 通过 base64 将 Value 反 编码 ， 如 图 10-7 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ echo -n MTIzNDU2 | base64 --decode 
123456ubuntu@k8s-master: ~$ 


ubuntuék8s-master:-$ echo -n YWRtaW4- | base64 --decode 
adminubuntuek8s-master : ~$ 
ubuntuék8s-master : ~$ 


图 10-7 
10.3 ”在 Pod 中 使 用 Secret 
Pod 可 以 通过 Volume 或 者 环境 变量 的 方式 使 用 Secret 。 


10.3.1 Volume 方式 
Pod 的 配置 文件 如 图 10-8 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 
name: mypod 
spec: 
containers: 
- name: mypod 
image: busybox 
args: 
- /bin/sh 
- -C 
- sleep 10; touch /tmp/healthy; sleep 
volumeMounts : 
- name: foo 
mountPath: 
readOnly: 
volumes: 
- name: foo 1 
secret: 
secretName: mysecret 


图 10-8 
@ 定义 volume foo， 来 源 为 secret mysecret 。 
@ 将 foo mount 到 容 絮 路 径 /etc/foo， 可 指定 读 写 权限 为 readOnly。 


创建 Pod 并 在 容器 中 读 取 Secret， 如 图 10-9 所 示 。 


8s-master: ~$ 

ubuntu@k8s-master:~$ kubectl apply -f mypod.yml 
pod "mypod" created 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl exec -it mypod sh 
/ # 

/ # 1s /etc/foo 


password username 

/ # 

/ # cat /etc/foo/username 
admin/ # 

/ € cat /etc/foo/password 
123456/ # 

[PW 


图 10-9 


可 以 看 到 ，Kubernetes 会 在 指定 的 路 径 /etcfoo 下 为 每 条 敏感 数据 创建 
一 个 文件 ， 文 件 名 就 是 数据 条 目的 Key， 这 里 是 /etc/foo/username 
和 和 /etc/foo/password，Value 则 以 明文 存放 在 文件 中 。 


我 们 也 可 以 目 定 义 存放 数据 的 文件 名， 比如 将 配置 文件 改 为 如 图 10-10 
所 示 那 样 。 


apiVersion: v1 
kind: Pod 
metadata: 

name: mypod 

spec: 

containers: 

- name: mypod 
image: busybox 
args: 

- /bin/sh 


- -C 
- sleep 10; touch /tmp/healthy; sleep 
volumeMounts : 


- name: foo 
mountPath: 
readOnly: 
volumes: 
- name: foo 
secret: 
secretName: mysecret 
items: 
- key: username 
path: my-group/my-username 
- key: password 
path: my-group/my-password 


10-10 


这 时 数据 将 分 别 存放 在 /etwfoo/my-group/my-username 和 /etc/foo/my- 
group/my-password 中 。 


以 Volume 方 式 使 用 的 Secret 支 持 动 态 更 新 : Secret sta, Bas PAYAL 
据 也 会 更 新 。 


将 password 更 新 为 abcdef ，base64 编 码 为 YWJjZGVm， 如 图 10-11 所 
ZN o 


apiVersion: v1 
kind: Secret 
metadata: 

name: mysecret 


data: 
username: YWRtaW4= 


password: YWJjZGVm 


图 10-11 


更 新 Secret， 如 图 10-12 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl apply -f mysecrete.yml 


secret "mysecret" configured 
ubuntuek8s -master : ~$ 


图 10-12 
几 秒 钟 后 ， 狐 的 password 会 同步 到 容 絮 ， 如 图 10-13 所 示 。 


/ # 
/ € cat /etc/foo/password 


/ 8 
/ # cat /etc/foo/password 


410-13 


10.3.2 ”环境 变量 方式 


通过 Volume 使 用 Secret， 容 器 必须 从 文件 读 取 数据 ， 稍 显扬 烦 ， 
Kubernetes 还 支持 通过 环境 变量 使 用 Secret 。 


Pod 配 置 文件 示例 如 图 10-14 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 

name: mypod 

spec: 

containers: 

- name: mypod 
image: busybox 
args: 

- /bin/sh 


-C 
sleep 10; touch /tmp/healthy; sleep 


name: SECRET. USERNAME 
valueFrom: 
secretKeyRef : 
name: mysecret 
key: username 
name: SECRET_PASSWORD 
vaLlueFrom: 
secretKeyRef : 
name: mysecret 
key: password 


图 10-14 


创建 Pod 并 读 取 Secret， 如 图 10-15 所 示 。 


ubuntuék8s-master :~$ 

ubuntuék8s-master:-$ kubectl apply -f mypod-env.yml 
pod "mypod" created 

ubuntu@k8s-master: ~$ 

ubuntuék8s-master:-$ kubectl exec -it mypod sh 

/ # 


/ # echo $SECRET_USERNAME 
admin 

/ # 

/ # echo $SECRET_PASSWORD 
abcdef 

Poe 


图 10-15 


通过 环境 变量 SECRET USERNAME 和 SECRET_ PASSWORD 成 功 读 取 
到 Secret 的 数据 。 


需要 注意 的 是 ， 环 境 变量 读 取 Secret 很 方便 ， 但 无 法 文 撑 Secret 动 态 更 
新 。 


10.4 ConfigMap 


Secret 可 以 为 Pod 提 供 密 码 、Token、 私 钥 等 敏感 数据 ;对 于 一 些 非 敏 
感 数据 ， 比 如 应 用 的 配置 信息 ， 则 可 以 用 ConfigMap 。 


ConfigMap 的 创建 和 使 用 方式 与 Secret 非 常 类 似 ， 主 要 的 不 同 是 数据 以 
明文 的 形式 存放 。 


与 Secret 一 样 ，ConfigMap 也 文 持 四 种 创建 方式 : 


(1) 通过 --from-literal: 


kubectl create configmap myconfigmap --from- 
literal-configi-xxx--from-literal-config2-yyy 


每 个 --from-literal 对 应 一 个 信息 条 目 。 
(2) 通过 --from-file: 

echo -n xxx > ./configt 

echo -n yyy > ./config2 


kubectl create configmap myconfigmap --from-file=./config1 -- 
from-file-./config2 


每 个 文件 内 容 对 应 一 个 信息 条 目 。 
(3) 通过 --from-env-file: 

cat << EOF > env.txt 

configi-xxx 

config2-yyy 


EOF 


kubectl create configmap myconfigmap --from-env-file=env.txt 
文件 envtxt 中 每 行 Key=Value 对 应 一 个 信息 条 目 。 


如 图 10-16 所 示 。 文 件 中 的 数据 直接 以 明 
B/N ? 


apiVersion: v1 
kind: ConfigMap 
metadata: 


: myconfigmap 


config2: yyy 
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与 Secret 一 样 ，Pod 也 可 以 通过 Volume 或 者 环境 变量 的 方式 使 用 


Secret ° 
(1) Volume 方 式 如 图 10-17 所 示 ° 


apiVersion: v1 
kind: Pod 
metadata: 

name: mypod 
spec: 

containers: 

- name: mypod 

image: busybox 

args: 

- /bin/sh 

- -C 

- sleep 10; touch /tmp/healthy; sleep 
volumeMounts : 

- name: foo 
mountPath: 
readOnly: 

volumes: 
- name: foo 
configMap: 
name: myconfigmap 


[10-17 


(2) 环境 变量 方式 如 图 10-18 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 

name: mypod 

spec: 

containers: 

- name: mypod 
image: busybox 
args: 

- /bin/sh 


- -C 
- sleep 10; touch /tmp/healthy; sleep 


- name: CONFIG_1 
valueFrom: 
configMapKeyRef : 
name: myconfigmap 
key: config1 
- name: CONFIG 2 
vaLueFrom: 
configMapKeyRef : 
name: myconfigmap 
key: config2 


图 10-18 


大 多 数 情 况 下 ， 配 萤 信息 都 以 文件 形式 提供 ， 所 以 在 创建 ConfigMap 
时 通常 采用 --from-file 或 YAML 方 式 ， 读 Ht ConfigMap 时 通常 采用 
Volume 方 式 。 比如 给 Pod 传 递 如 何 记录 日 志 的 配置 信息 ， 如 图 10- 19 所 
7Re 


class: Logging.handlers.RotatingFileHandler 
formatter: precise 


level: INFO 
filename: %hostname-%timestamp. log 


图 10-19 


可 以 采用 --from-file 形 式 . 将 其 保存 在 文件 logging.conf 中 ， 然 后 执行 命 
T: 


kubectl create configmap myconfigmap --from-file=./logging.conf 


如 果 采 用 YAML 配 置 文件 ， 其 内 容 则 如 图 10-20 所 示 。 


apiVersion: v1 
kind: ConfigMap 
metadata: 

name: myconfigmap 
data: 


logging.conf: | 
class: logging.handlers.RotatingFileHandler 
formatter: precise 
Level: INFO 
filename: %hostname-%timestamp. log 


图 10-20 
注意 ， 别 漏 写 了 Key logging.conf 后 面 的 | 符号 。 
创建 并 查看 ConfigMap， 如 图 10-21 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f myconfigmap.yml 
configmap "myconfigmap" created 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get configmap myconfigmap 

NAME DATA AGE 

myconfigmap 1 12s 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl describe configmap myconfigmap 
Name: myconfigmap 

Namespace: default 

Labels: <none> 

Annotations: kubectl.kubernetes.io/last-applied-configuration-("apiVersion" : "v1" 


e-Xtimestamp... 


: precise 
: INFO 


Events: <none> 
ubuntu@k8s-master : ~$ 


图 10-21 


在 Pod 中 使 用 此 ConfigMap， 配 置 文件 如 图 10-22 所 示 。 


apiVersion: v1 
kind: Pod 
metadata: 

name: mypod 

spec: 

containers: 

- name: mypod 
image: busybox 
args: 

- /bin/sh 


- =C 


- sleep 10; touch /tmp/healthy; sleep 
volumeMounts : 
- name: foo 25 
mountPath : = 
voLumes: 
- name: foo 
configMap : 
name: myconfigmap 
items: 
- key: Logging. conf 
path: myapp/Logging. conf 


图 10-22 


© 在 volume 中 指定 存放 配置 信息 的 文件 相对 路 径 为 
myapp/logging.conf ° 


Q volume mount 到 容器 的 /etc 目 孙 。 
创建 Pod 并 读 取 配置 信息 ， 如 图 10-23 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl apply -f mypod.yml 
pod "mypod" created 

ubuntuek8s -master : ~$ 

ubuntuék8s-master:-$ kubectl exec -it mypod sh 
/ # 


/ € cat /etc/myapp/logging.conf 

class: lLogging.handLlers.RotatingFileHandler 
formatter: precise 

LeveL: INFO 

filename: %hostname-%timestamp.log 

/ # 


图 10-23 


配置 信息 已 经 保存 到 /etc/myapp/logging.conf 文 件 中 。 与 Secret 一 样 ， 
Volume 形 式 的 ConfigMap 也 支持 动态 更 新 ， 留 给 大 家 上 自己 实践 。 


10.5 小结 


本 划 我 们 学 习 了 如 何 癌 Pod 传 递 配置 信息 。 如 果 信 息 需 要 加 密 ， 可 使 
用 Secret; 如 采 是 一 般 的 配置 信息 ， 则 可 使 用 ConfigMap 。 


Secret 和 ConfigMap 文 持 四 种 定义 方法 。Pod 在 使 用 它们 时 ， 可 以 选择 
Volume 方 式 或 环境 变量 方式 ， 不 过 只 有 Volume 方 式 文 持 动 态 更 新 。 


第 11 章 ”Helm Kubernetes 的 包 管 理 
aW 


本 章 我 们 将 学 习 Helm 


每 个 成 功 的 软件 平台 都 有 一 个 优秀 的 打包 系统 ， 比 如 Debian、Ubuntu 
的 apt，Red Hat ^ CentOSÉ yum ° Helmlll|z& Kubernetes EF HJ EJ Ell gs ° 


本 章 我 们 将 讨论 为 什么 需要 Helm、 它 的 架构 和 组 件 ， 以 及 如 何 使 用 
Helm ° 


11.1 Why Helm 


Helm 到 展 解 决 了 什么 问题 ? 为 什么 Kubernetes 需 要 Helm? 


答案 是 : Kubernetes 能 够 很 好 地 组 织 和 编排 容器 ， 但 它 缺 少 一 个 更 高 
层次 的 应 用 打包 工具 ， 而 Helm 残 是 来 干 这 件 事 的 。 


先 来 看 个 例子 。 


比如 对 于 一 个 MySQL 服 务 ，Kubernetes 需 要 部 署 下 面 这 些 对 象 : 


Kubernetes 的 包 管 理 器 。 


(1) Service， 让 外 界 能 够 访问 到 MySQL， 如 图 11-1 所 示 。 


apiVersion: v1 
kind: Service 
metadata: 
name: my-mysql 
Labels: 
app: my-mysql 


- name: mysql 

port: 

targetPort: mysql 
selector: 

app: my-mysql 
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(2) Secret， 定 义 MySQL 的 密码 ， 如 图 11-2 所 示 。 


apiVersion: v1 
kind: Secret 
metadata: 
name: my-mysql 
labels: 
app: my-mysql 
type: Opaque 
data: 
mysql-root-password: 
mysql-password: 


图 11-2 


(3) PersistentVolumeClaim ， 为 MySQL 申 请 持久 化 存储 空间 ， 如 图 11- 
3 所 示 。 


kind: PersistentVolumeClaim 
apiVersion: v1 
metadata: 
name: my-mysql 
labels: 
app: my-mysql 


spec: 
accessModes: 


resources: 
requests: 
storage: 


图 11-3 


(4) Deployment， 部 署 MySQL Pod， 并 使 用 上 面 的 这 些 支持 对 象 ， 
图 11-4 所 示 。 


apiVersion: extensions/vibetal 
kind: Deployment 
metadata: 
name: my-mysql 
labels: 
app: my-mysql 
spec: 
template: 
metadata: 
Labels: 
app: my-mysql 
spec: 
containers: 
- name: my-mysql 
image: 
env: 
- name: MYSQL_ROOT_PASSWORD 
valueFrom: 
secretKeyRef : 
name: my-mysql 
key: mysql-root-password 
name: MYSQL_PASSWORD 
valueFrom: 
secretKeyRef : 
name: my-mysql 
key: mysql-password 
name: MYSQL. USER 
value: 
name: MYSQL_DATABASE 
value: 
ports: 
- name: mysql 
containerPort: 
volumeMounts : 
- name: data 
mountPath: /var/lib/mysql 
volumes: 
- name: data 
persistentVolumeClaim: 
claimName: my-mysql 


图 11-4 


如 


我 们 可 以 将 上 面 这 些 配 置 保存 到 对 象 各 上 自 的 文件 中 ， 或 者 集中 写 进 一 
个 配置 文件 ， 然 后 通过 kubectl apply -f 部 署 。 


到 目前 为 止 ，Kubernetes 对 服务 的 部 署 支持 得 都 挺 好 ， 如 果 应 用 只 由 
一 个 或 儿 个 这 样 的 服务 组 成 ， 上 面 的 部 署 方式 完全 足够 了 。 


但 是 ， 如 采 我 们 开发 的 是 微 服务 架构 的 应 用 ， 组 成 应 用 的 服务 可 能 多 
达 十 个 甚至 几 十 上 百 个 ， 这 种 组 织 和 管理 应 用 的 方式 就 不 好 使 了 : 


(1) 很 难 管理 、 编 辑 和 维护 如 此 多 的 服务 。 每 个 服务 都 有 若干 配置 ， 
缺乏 一 个 更 高 层次 的 工具 将 这 些 配置 组 织 起 来 。 


(2) 不 容易 将 这 些 服务 作为 一 个 整体 统一 发 布 。 部 署 人 员 需 要 首先 理 
解 应 用 都 包含 哪些 服务 ， 然 后 按照 逻辑 顺序 依次 执行 kubectl apply, BH 
缺少 一 种 工具 来 定义 应 用 与 服务 ， 以 及 服务 与 服务 之 间 的 依赖 关系 。 

(3) 不 能 高 效 地 共享 和 重用 服务 。 比 如 两 个 应 用 都 要 用 到 MySQL 服 
务 ， 但 配置 的 参数 不 一 样 ， 这 两 个 应 用 只 能 分 别 复制 一 套 标 准 的 
MySQL 配 置 文件 ， 修 改 后 通过 kubectl apply 部 署 。 也 就 是 说 ， 不 文 持 
参数 化 配置 和 多 环境 部 署 。 


(4) 不 支持 应 用 级 别 的 版 本 管理 。 虽 然 可 以 通过 kubectl rollout undo 
进行 回 演 ， 但 这 只 能 针对 单个 Deployment， 不 支持 整个 应 用 的 回 深 。 

(5) 不 支持 对 部 署 的 应 用 状态 进行 验证 。 比 如 是 否 能 通过 预定 义 的 账 
号 访问 MySQL。 虽然 Kubernetes 有 健康 检查 ， 但 那 是 针对 单个 容 必 ， 
我 们 需要 应 用 (服务 ) 级 别 的 健康 检查 。 


Helm 能 够 解决 上 面 这 些 问 题 ，Helm 帮 助 Kubernetes 成 为 微服 务 架 构 应 
用 理想 的 部 署 平 台 。 


11.2 Helm 架构 
在 实践 之 前 ， 我 们 先 来 看 看 Helm 的 架构 。 
Helm 有 两 个 重要 的 概念 : chart 和 release ° 


。 chart 是 创建 一 个 应 用 的 信息 集合 ， 包 括 各 种 Kubernetes 对 象 的 配 
置 模 板 、 参 数 定义 、 依 赖 关 系 、 文 档 说 明 等 。chart 是 应 用 部 署 的 
目 包 SiR o 可 以 将 chart 想 象 成 apt 、 yun FAK Pace 装 包 。 

。 release 是 chart 的 运行 实例 ， 代 表 了 一 个 正在 运行 的 应 用 。 当 chart 
被 安装 see parade HE, MÆ T release ° charthe ls Ze KL 

到 同一 个 集群 ， 每 次 安装 都 是 一 个 release 。 


Helm 是 包 管 理工 具 ， 这 里 的 包 就 是 指 的 chart。Helm 能 够 : 
从 零 创 建新 chart。 
与 存储 chart 的 仓库 交互 ， 拉 取 、 保 在 和 更 新 chart 。 


在 Kubernetes 集 群 中 安装 和 外 载 release。 
更 新 、 回 秘 和 测试 release。 


Helm 包 含 两 个 组 件 : Helm 客 户 端 和 Tiller 服 务 器 ， 如 图 11-5 所 示 。 


Kubernetes 


| 
Helm | gRPC | f 22] 
Client | pes J 


图 11-5 
Helm 客 户 端 是 终端 用 户 使 用 的 命令 行 工具 ， 用 户 可 以 : 


e. 在 本 地 开发 chart。 

管理 chart 人 仓库。 

与 Tiller 服 务必 交互 

在 远程 Kubernetes 集 群 上 安装 chart。 
查看 release 信 息 。 


。 升级 或 印 载 已 有 的 release ° 


Tiller 服 务 器 运行 在 Kubernetes 集 群 中 ， E UE WE Veg OK , 
与 ee API Server H. ° Tiller]lkóS z8 £1 T: 


监听 来 和 目 Helm 客 户 端的 请 求 。 

通过 chart 构 建 release o 

在 Kubernetes 中 安装 chart， 并 跟踪 release 的 状态 。 
通过 API Servers ARREA 的 release。 


简单 地 讲 ，Hem 客 户 端 负责 管理 chart，Tiller 服 务 器 负责 管理 release。 


11.3 ”安装 Helm 


本 下 我 们 将 依次 安装 Helm 客 户 端 和 Tiller 服 务 器 。 


11.3.1 Helm E P8 


通常 ， 我 们 将 Helm 客 户 端 安 装 在 能 够 执行 kubectl 命 令 的 节点 上 ， 只 需 
要 下 面 一 条 命令 


curl https://raw.githubusercontent.com/kubernetes/helm/master/s 
cripts/get | bash 


结果 如 图 11-6 所 示 。 


alt 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get | bash 
% Total % Received % Xferd Average Speed Time Time Time Current 
Dload Upload Total Spent Lon Speed 


100 6329 100 6329 0 0 4179 0 0:00:01 0:00:01 - 4180 
Downloading https://kubernetes-helm.storage.googleapis.com/helm- v2. 2.6. 2- Tinus amd64. tar .gz 
Preparing to install into /usr/local/bin 

helm installed into /usr/local/bin/helm 

Run 'helm init' to configure helm. 

ubuntu@k8s-master: ~$ 


图 11-6 


执行 helm version 难 证 ， 如 图 11-7 所 示 。 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ helm version 
Client: &version.Version{SemVer:"v2.7.@", GitCommit:"08c1144f5eb3e3b636 


d9775617287cc26e53dba4", GitTreeState:"clean"} 
Error: cannot connect to Tiller 
ubuntu@k8s-master: ~$ 


图 11-7 
目前 只 能 查看 到 客户 端的 版 本 ， 服 务 器 还 没有 安装 。 


helm 有 很 多 子 命令 和 参数 ， 为 了 提高 使 用 命令 行 的 效率 ， 通 种 建议 安 
冯 helm 的 bash 命 令 补 全 脚本 ， 方 法 如 下 : 


helm completion bash > 


重新 登录 后 就 可 以 通 
ZK œ 


ubuntu@k8s-master: -$ 

completion get 
history 
home 
init 
inspect 

ubuntu@k8s-master :~$ 


ubuntu@k8s-master :~ 


.helmrc echo "source 


过 Tab 键 补 全 heljm 子 命令 


helm 

install 

lint 

list 

package 

plugin 
helm install -- 
--name- 
--namespace- 
--name-template- 
--no-hooks 
--replace 
--repo- 
--set= 
--tiller-namespace- 
--timeout- 
--tls 


status 
template 
test 
upgrade 
verify 


repo 
reset 
rollback 
search 
serve 


--tls-ca-cert= 
--tls-cert- 
--tls-key- 
--tls-verify 
--values- 
--verify 
--version- 
--wait 


图 11-8 


11.3.2. ” Tiller 服务器 


Tiller 服 务 器 安 
7R o 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ helm 


BBS AR TS f] E , 


init 


$HELM_HOME has been configured at /home/ubuntu/.helm. 


.helmrc" 


>> „bashrc 


和 参数 了 ， 如 图 11-8 所 


version 


只 需要 执行 helm init 即 可 ， 如 图 11-9 所 


Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster. 
Happy Helming! 
ubuntu@k8s-master: ~$ 


图 11-9 


Tiller 本 身 也 是 作为 容器 化 应 用 运行 在 Kubernetes Cluster 中 的 ， 如 图 11- 


10 所 示 。 


ubuntu@k&8s-master : ~$ 


ubuntu@k8s-master:~$ kubectl get --namespace=kube-system svc tiller-deploy 


NAME CLUSTER-IP 
tiller-deploy 10.98.124.71 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get --namespace-kube-system deployment tiller-deploy 
NAME DESIRED 


CURRENT 
tiller-deploy 1 1 
ubuntu@k8s-master : ~$ 


ubuntuék8s-master:-$ kubectl get --namespace-kube-system pod tiller-deploy-1936853538-c8sfp 
NAME READY 
tiller-deploy-1936853538-c8sfp 1/1 


ubuntu@k8s-master: ~$ 


EXTERNAL- 
<none> 


UP-TO-DATE 


IP  PORTCS) AGE 
44134/TCP — 1m 


AVAILABLE AGE 
1 1m 


STATUS RESTARTS AGE 
Running 0 2m 


图 11-10 


可 以 看 到 Tiller 的 Service、Deployment 和 Pod 。 


现在 ，helm version 已 经 能 够 查看 到 服务 


示 o 


root@k8s-master:~# helm version 


Client: &version.Version{SemVer: "v2.7.0", 


26e53dba4", GitTreeState:"clean"} 
Server: 


26e53dba4", GitTreeState:"clean"} 


11.4 ”使 用 Helm 
装 成 功 后 ， 可 执行 helm search 查 看 当前 可 安装 


Helm 安 
12 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ helm search 
NAME 

Local/cool-chart 
stable/acs-engine-autoscaler 
stable/artifactory 
stable/aws-cluster-autoscaler 
stable/buildkite 
stable/centrifugo 
stable/chaoskube 
stable/chronograf 
stable/cluster-autoscaler 
stable/cockroachdb 
stable/concourse 
stable/consul 

stable/coredns 
stable/coscale 
stable/dask-distributed 
stable/datadog 
stable/dokuwiki 
stable/drupal 
stable/etcd-operator 


E 


SBSSONSGOSSSSDSDDONOGDOANG< 


&version.Version{SemVer: "v2.7.0", 


© 
N 


VIPNWONUANUNWUONWRREPR 29 
©: 


图 11-11 


SION DESCRIPTION 


A Helm chart for Kubernetes 
Scales worker nodes within agent pools 


Universal Repository Manager supporting all maj... 


Scales worker nodes within autoscaling groups. 
Agent for Buildkite 
Centrifugo is a real-time messaging server. 


Chaoskube periodically kills random pods in you... 
Open-source web application written in Go and R... 


Scales worker nodes within autoscaling groups. 


CockroachDB is a scalable, survivable, strongly... 


Concourse is a simple and scalable CI system. 


Highly available and distributed service discov... 
CoreDNS is a DNS server that chains middleware ... 


CoScale Agent 
Distributed computation in Python 
DataDog Agent 


DokuWiki is a standards-compliant, simple to us... 
One of the most versatile open source content m... 


CoreOS etcd-operator Helm chart for Kubernetes 


GitCommit : "08c1144f5eb3e3b636d9775617287cc 


GitCommit:"08c1144f5eb3e3b63649775617287cc 


的 chart， 


右 的 版 本 信息 了 ， 如 图 11-11 所 


如 图 11- 


图 11-12 


个 列表 很 长 ， 这 里 只 截取 了 一 部 分 。 大 家 不 体会 问 ， 这 些 chart 都 是 
从 哪里 来 的 ? 


前 面 说 过 ，Helm 可 以 像 apt 和 和 yum 管理 软件 包 一 样 管理 chart。apt 和 yum 
的 软件 包 存 放 在 仓库 中 ， 同 样 的 ，Helm 也 有 仓库 ， 如 图 11-13 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ helm repo list 
NAME URL 


stable https://kubernetes-charts.storage.googleapis.com 


local http://127.0.0.1:8879/charts 
ubuntu@k8s-master:~$ 


图 11-13 


Helm 安 装 时 已 经 默认 配置 好 了 两 个 仓库 : stableflllocal ° stablezé E 77 
仓库 ，local 是 用 户 存放 目 己 开发 的 chart 的 本 地 仓库 。 


helm search 会 显示 chart 位 于 哪个 仓库 ， 比 如 localcool-chart 和 stable/acs- 
engineautoscaler ° 


用 户 可 以 通过 helm repo add 添 加 更 多 的 仓库 ， 比 如 企业 的 私有 仓库 ， 
仓库 的 管理 和 维护 方法 请 参考 官网 文档 https:/docs.helm.sh。 


与 apt 和 yum 一 样 ，helm 也 文 持 关键 字 搜 索 ， 如 图 11-14 所 示 。 包 括 
D NE 竺 内 的 所 有 信息 ， 只 要 跟 关 键 字 匹配 ， 都 会 显示 在 结果 
| 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ helm search mysql 

NAME VERSION DESCRIPTION 

stable/mysql 0.3.0 Fast, reliable, scalable, and easy to use open-... 


free, fully compatible, enhanced, open source d... 


0.3.0 
y 09.2.0 Google Cloud SQL Proxy 
2.0.0 Fast, reliable, scalable, and easy to use open-... 


ubuntu@k8s-master : ~$ 


图 11-14 
闭 chart 也 很 答 单 ， 执 行 如 下 命令 束 可 以 安装 MySQL 。 


helm install stable/mysql 


如 果 看 到 如 图 11-15 所 示 的 报错 ， 通 常 是 因为 Tiller 服 务 器 的 权限 不 足 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ helm install stable/mysql 


Error: no available release name found 
ubuntu@k8s-master: ~$ 


图 11-15 
执行 如 下 命名 添加 权限 : 
kubectl create serviceaccount --namespace kube-system tiller 


kubectl create clusterrolebinding tiller-cluster-rule -- 
clusterrole=cluster-admin --serviceaccount=kube-system:tiller 


kubectl patch deploy --namespace kube-system tiller-deploy - 
p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}' 


然后 再 次 执行 下 面 的 命令 ， 结 果 如 图 11-16 所 示 。 


helm install stable/mysql 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ helm install stable/mysql 
NAME:  fun-zorse (1 

LAST DEPLOYED: Tue Oct 17 11:34:55 2017 
NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 2) 

==> v1/Service 

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
fun-zorse-mysql 10.108.23.5 <none> 3306/TCP 0s 

==> Vibetal/Deployment 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
fun-zorse-mysql 1 E 1 0 Qs 
==> vi/Secret 

NAME TYPE DATA AGE 

fun-zorse-mysql Opaque 2 1s 

==> vi1/PersistentVoLumeClaim 


NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE 
fun-zorse-mysql Pending 1s 


ny em be accessed via port 3306 on the following DNS name from within your cluster: 
fun-zorse-mysql.default.svc.cluster. local 
To get your root password run: 
kubectl get secret --namespace default fun-zorse-mysql -o jsonpath="{.data.mysql-root-passwor 
connect to your database: 
. Run an Ubuntu pod that you can use as a client: 


kubectl run -i --tty ubuntu --image-ubuntu:16.04 --restart-Never -- bash -il 


. Install the mysql client: 


$ apt-get update && apt-get install mysql-client -y 


. Connect using the mysql cli, then provide your password: 
$ mysql -h fun-zorse-mysql -p 


图 11-16 
输出 分 为 三 部 分 : 
© chart 本 次 部 署 的 描述 信息 o 


。NAME 是 release 的 名 字 ， 因 为 我 们 没 用 -n 参 数 指定 ， 所 以 Helm 随 
机 生成 了 一 个 ， 这 里 是 fun-zorse 。 

e NAMESPACE 是 release 部 署 的 namespace， 默 认 是 default， 也 可 以 
通过 --namespace 指 定 。 

e STATUS 为 DEPLOYED， 表 示 已 经 将 chart 部 署 到 集群 。 


@ 当前 release 包含 的 资源 : Service ^ Deployment ^ Secret 和 
PersistentVolumeClaim ， 其 名 字 都 是 fun-zorse-mysql， 命 名 的 格式 为 
ReleasName-ChartName ° 


@ NOTES 部 分 显示 的 是 release 的 使 用 方法 ， 比 如 如 何 访问 Service、 如 
何 获取 数据 库 密 人 码 以 及 如 何 连 接 数据 库 等 。 


通过 kubectl get 可 以 查看 组 成 release 的 各 个 对 象 ， 如 图 11-17 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get service fun-zorse-mysql 

NAME CLUSTER-IP EXTERNAL - IP PORTCS) AGE 

fun-zorse-mysql 10.108.23.5 | «none» 3306/TCP 15m 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get deployment fun-zorse-mysql 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
fun-zorse-mysql £ 1 1 0 15m 
ubuntuék8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get pod fun-zorse-mysql-2959529493-hfqit 

NAME READY STATUS RESTARTS AGE 
fun-zorse-mysql-2959529493-hfqit 0/1 Pending 0 15m 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get pvc fun-zorse-mysql 

NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE 
fun-zorse-mysql Pending 15m 
ubuntu@k8s-master : ~$ 


图 11-17 
因为 我 们 还 没有 准备 PersistentVolume， 所 以 当前 release 还 不 可 用 。 


helm list 显 示 已 经 部 署 的 release helm delete 可 以 删除 release， 如 图 11- 
18 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ helm list 

NAME REVISION UPDATED STATUS CHART 
fun-zorse 1 Tue Oct 17 11:34:55 2017 DEPLOYED mysql-@.3.0 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ helm delete fun-zorse 


release "fun-zorse" deleted 
ubuntu@k8s-master : ~$ 


图 11-18 


iuda 使 用 方法 像 极 了 apt 和 yum， 用 Helm 来 管理 Kubernetes 应 用 非常 


11.5 charti Ef 


chart 是 Helm 的 应 用 打包 格式 。chart 由 一 系列 文件 组 成 ， 这 些 文件 描述 
了 Kubernetes 部 署 应 用 时 所 需要 的 资源 ， 比 如 Service、Deployment、 
PersistentVolumeClaim 、Secret、ConfigMap 等 。 


单个 的 chart 可 以 非常 简单 ， 只 用 于 部 署 一 个 服务 ， 比 如 Memcached ° 
chart 也 可 以 很 复杂 ， 部 署 整个 应 用 ， 比 如 包含 HITP Servers ^ 
Database、 消 息 中 间 件 、Cache 等 。 


chart 将 这 些 文件 放置 在 预定 义 的 目录 结构 中 ， 通 第 整个 chart 被 打 成 tar 
包 ， 而 且 标注 上 版 本 信息 ， 便 于 Helm 部 警 。 


下 面 我 们 将 详细 讨论 chart 的 目 孙 结构 以 及 包含 的 各 类 文件 o 
11.5.4 chart EH Ft 


Ll AI [f] MySQL chart 7j fy] « — EL Z% f dE ^ chart , EX RE AT 以 在 
~-/.helmycache/archive 中 找到 chart 的 tar 包 ， 如 图 11-19 所 示 。 


ubuntu@k8s-master: ~$ 


ubuntu@k8s-master:~$ ls ~/.helm/cache/archive 
mysql-0.3.0.tgz 
ubuntu@k8s-master: ~$ 


图 11-19 


解压 后 ，MySQL chart 目 好 结构 如 图 11-20 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ tree mysql 
mysql 
H— Chart.yaml 
HF-— README.md 
上- 一 templates 

I— configmap.yaml 

F— deployment.yaml 

LI-— .helpers.tpl 


H- pvc.yaml 
H— secrets.yaml 
L—— svc.yaml 

L— values.yaml 


| 
| 
| 
| I— NOTES.txt 
| 
| 
| 


1 directory, 10 files 
ubuntu@k8s-master : ~$ 


图 11-20 


目录 名 就 是 chart 的 名 字 (不 带 版 本 信息 ) ， 这 里 是 mysql， 包 含 如 下 内 
X o 


(1) Chart.yaml 
YAML 文 件 ， 描 述 chart 的 概要 信息 ， 如 图 11-21 所 示 。 


description: Fast, reliable, scalable, and easy to use open-source relational database 
system, 

engine: gotpl 

home: https://www.mysql.com/ 

icon: https://www.mysql.com/common/logos/logo-mysql-170x115.png 

keywords: 

- mysql 

- database 

- sql 

maintainers: 

- email: viglesias@google.com 
name: Vic Iglesias 

name: mysql 

sources: 


- https: //github.com/kubernetes/charts 
- https://github.com/docker-library/mysql 
version: 0.3.0 


[11-21 
name 和 version 是 必 填 项 ， 其 他 都 是 可 选项 。 
(2) README.md 


Markdown 格 式 的 README 文 件 ， 相 当 于 chart 的 使 用 文档 ， 此 文件 为 
可 选 ， 如 图 11-22 所 示 。 


) is one of the most popular database servers in the world. Notable users includ 


This chart bootstraps a single node MySQL deployment on a [Kk 
Prer 


Kubernetes 1.64 with Beta APIs enabled 
- PV provisioner support in the underlying infrastructure 


ns 111 


To install the chart with the release name ‘my-release : 


bast 


$ helm install --name my-release stable/mysql 


The command deploys MySQL on the Kubernetes cluster in the default configuration. The [configuration]C 


By default a random password will be generated for the root user. If you'd like to set your own password 
in the values.yaml. 


You can retrieve your root password by running the following command. Make sure to replace [YOU | 1238333 | 
printf $(printf 'NXo' "kubectl get secret [YOUR RELEASE NAME]-mysql -o jsonpath="{.data.mysql-root-pa| 


图 rip 国 : List all releases using “helm list 


To uninstall/delete the ‘my-release deployment: 


bash 
$ helm delete my-release 


The command removes all the Kubernetes components associated with the chart and deletes the release. 
+ 人 ntigurat 

The following tables lists the configurable parameters of the MySQL chart and their default values. 
Parameter Description Default 


imageTag mysql image tag. Most recent release 
imagePullPolicy Image pull policy IfNotPresent 
mysqlRootPassword Password for the ‘root’ user. nil 

mysqlUser Username of new user to create. nil 

mysqlPassword Password for the new user. nil 

mysqlDatabase Name for new database to create. nil 


图 11-22 
(3) LICENSE 
文本 文件 ， 摘 述 chart 的 许可 信息 ， 此 文件 为 可 选 。 
(4) requirements.yaml 


chart 可 能 依赖 其 他 的 chart， 这 些 依赖 关系 可 通过 requirements.yaml 指 
定 ， 如 图 11-23 所 示 。 


dependencies: 
- name: rabbitmq 
version: 1.2.3 
repository: http://example.com/charts 


name: memcached 
version: 3.2.1 
repository: http://another.example.com/charts 


图 11-23 
在 安装 过 程 中 ， 依 赖 的 chart 也 会 被 一 起 安装 。 
(5) values.yaml 


chart 文 持 在 安装 时 根据 参数 进行 定制 化 配置 ， 而 values.yaml 则 提供 了 
这 些 配置 参数 的 默认 值 ， 如 图 11-24 所 示 。 


## mysql image version 
image: "mysql" 
imageTag: "5.7.14" 


## Specify password for root user 

## 

## Default: random 10 character string 
# mysqlRootPassword: testing 


## Create a database user 
## 

# mysqlUser: 

# mysqlPassword: 


imagePullPolicy: IfNotPresent 
## Persist data to a persitent volume 


persistence: 
enabled: true 


## If defined, storageClassName: <storageClass> 


nn 


## If set to "-", storageClassName: 
## 

# storageClass: "-" 
accessMode: ReadWriteOnce 
size: 8Gi 


, which disables dynamic provisioning 


## Configure resource requests and limits 
## 
resources: 
requests: 
memory: 256Mi 
cpu: 100m 


# Custom mysql configuration files used to override default mysql settings 
configurationFiles: 

# mysql.cnf: |l- 

# [mysqld] 

# skip-name-resolve 


图 11-24 
(6) templates H 5& 


各 类 Kubernetes 资 源 的 配置 模板 都 放置 在 这 里 。Helm 会 将 values.yaml 
中 的 参数 值 注 入 模板 中 ， 生 成 标准 的 YAML 配 置 文件 。 


模板 是 chart 最 重要 的 部 分 ， 也 是 Helm 最 强大 的 地 方 。 模 板 增加 了 应 用 
部 警 的 灵活 性 ， 能 够 适用 不 同 的 环境 ， 我 们 后 面 会 详细 讨论 。 


(7) templates/NOTES.txt 


PEE chart 安 装 成 功 后 会 显示 此 文档 内 容 ， 如 图 11-25 
ZR œ 


MySQL can be accessed via port 3306 on the following DNS name from within your cluster: 
íi template "mysql.fullname" . }}.{{ .Release.Namespace }}.svc.cluster.local 


To get your root password run: 


kubectl get secret --namespace {{ .Release.Namespace }} {{ template "mysql.fullname" . }} 


To connect to your database: 
1. Run an Ubuntu pod that you can use as a client: 

kubectl run -i --tty ubuntu --image-ubuntu:16.04 --restart-Never -- bash -il 
2. Install the mysql client: 

$ apt-get update && apt-get install mysql-client -y 


3. Connect using the mysql cli, then provide your password: 
$ mysql -h {{ template "mysql.fullname" . 1] -p 


图 11-25 


2 模板 一 样 ， 可 以 在 NOTE.txt 中 插入 配置 参数 ，Helm 会 动态 注入 参数 


11.5.2 chartz 


Helm 通 过 模板 创建 Kubernetes 能 够 理解 的 YAML 格 式 的 资源 配置 文 
件 ， 我 们 将 通过 例子 来 学 习 如 何 使 用 模板 。 


以 templates/secrets.yaml 为 例 ， 如 图 11-26 所 示 。 


apiVersion: v1 
kind: Secret 
metadata: 
name: {{ template 
Labels: 
app: {{ template 
chart: 
release: 
heritage: 
type: Opaque 
data: 
[f if .Values. ed J 
nieni root-password: {{ .Values. hice ear | b64enc | quote }} 
tt else $F 
mysql-root-password: {{ randAlphaNum | b64enc | quote }} 
{{ i end } H 
{{ if .Values.mysqlPassword }} 
mysql-password: {{ .Values.mysqlPassword | b64enc | quote }} 
{{ else }} 
mysql-password: {{ randAlphaNum | b64enc | quote }} 
{{ end }} 


图 11-26 


从 结构 上 看 ， 文 件 的 内 容 非常 像 Secret 配 置 ， 只 是 大 部 分 属性 值 变 成 了 
{{ xxx }}。 这 些 {{ xxx DEP LERH EA 。 Helm 采 用 了 Go 语言 的 
模板 来 编写 chart。Go 模 板 非常 强大 ， 文 持 变 量 、 对 象 、 画 数 、 流 控制 
等 功能 。 下 面 我 们 通过 解析 templates/secrets.yaml 快 速 学 习 模 板 。 


(D {{ template "mysql.fullname" . }} 定 义 Secret 的 name。 天 键 字 template 
的 作用 是 引用 一 个 子 模板 mysqlfullname。 这 个 子 模 板 是 在 
templates/_helpers.tpl 文 件 中 定义 的 ， 如 图 11-27 所 示 。 


{{/* vim: set filetype=mustache: */}} 

Lis 

Expand the name of the chart. 

*/H 

{{- define "mysql.name" -}} 

{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" -}} 
{{- end -}} 


H 

Create a default fully qualified app name. 

We truncate at 63 chars because some Kubernetes name fields are limited to this 
LA! 


{{- define "mysql.fullname" -}} 

{{- $name := default .Chart.Name .Values.nameOverride -}} 

{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" -}} 
{{- end -}} 


图 11-27 


SE DURE REAN, ANE HE TREA PNR ^ EA ^ Ti 
控制 等 概念 。 现 在 看 不 懂 没 关系 ， 这 里 我 们 学 习 的 重点 是 : 如 果 存 在 
一 些 信息 多 个 模板 都 会 用 到 ， 则 可 在 templates/_helpers.tpl 中 将 其 定义 
为 子 模板 ， 然 后 通过 templates 函 数 引 用 。 


这 里 mysql.fullname 是 由 release 与 chart 二 者 名 字 拼 接 组 成 的 。 
根据 chart 的 最 佳 实 践 ， 所 有 资源 的 名 称 都 应 该 保持 一 致 。 对 于 我 们 这 
个 chart ， 无 论 Secret 还 是 Deployment ^ PersistentVolumeClaim ^ 


Service， 它 们 的 名 字 都 是 子 模板 mysql.fullname 的 值 。 


@ Chart 和 Release 是 Helm 预 定义 的 对 象 ， 每 个 对 象 都 有 目 己 的 属性 ， 
可 以 在 模板 中 使 用 。 如 果 使 用 下 面 的 命令 安装 chart: 


helm install stable/mysql -n my 
那么 : 


e {{ .Chart.Name HJA mysql ° 

e {{ .Chart.Version }} 的 值 为 0.3.0。 

e {{ .Release.Name }} 的 值 为 my ° 

e {{ .Release.Service }} 始 终 取 值 为 Tiller ° 

e (( template "mysql.fullname" . }} 计 算 结 果 为 my-mysql。 


© 这 里 指定 mysql-root-password 的 值 ， 不 过 使 用 了 if-else 的 流 控 制 ， 其 
逻辑 为 : 如果 .Values.mysqlRootPassword 有 值 ， 就 对 其 进行 base64 编 
码 ， 否 则 随机 生成 一 个 10 位 的 字符 串 并 编码 。 


Values 也 是 预定 义 的 对 象 ， 代 表 的 是 values.yaml X 
fF 。 .Values.mysqlRootPassword Jl] 是 values.yaml 中 定义 的 
mysqlRootPassword 参 数 ， 如 图 11-28 所 示 。 


## mysql image version 
HH 

image: "mysql" 
imageTag: "5.7.14" 


## Specify password for root user 

HH 

## Default: random 10 character string 
# mysqlRootPassword: testing 


## Create a database user 
TE 

# mysqlUser: 

# mysqlPassword: 


[11-28 


为 mysqlRootPassword 被 注释 掉 了 ， 没 有 赋值 ， 所 以 逻辑 判断 会 走 
else， 即 随机 生成 密码 。 


randAlphaNum、b64enc、quote 都 是 Go 模板 语言 文 持 的 函数 ， 函 数 之 
间 可 以 通过 管道 | 连接 。{{f randAlphaNum 10 | b64enc | quote }} 的 作用 
是 首先 随机 产生 一 个 长 度 为 10 的 字符 串 ， 然 后 将 其 base64 编 码 ， 最 后 
两 边 加 上 双 引 号 。 


templates/secrets.yaml 这 个 例子 展示 了 chart 模 板 主要 的 功能 ， 我 们 最 大 
o ae 模板 将 chart 参 数 化 了 ， 通 过 values.yaml 可 以 灵活 定制 
MH e 


无 论 多 复杂 的 应 用 ， 用 户 都 可 以 用 Go 模板 语言 编写 出 chart。 无 非 是 使 
用 到 更 多 的 函数 、 对 象 和 流 控制 。 对 于 初学 者 ， 建 议 尽量 参考 官方 的 
chart。 根 据 二 八 定律 ， 这 些 chart 已 经 覆盖 了 绝 大 部 分 情况 ， 而 且 采 用 
了 最 佳 实 践 。 如 何 遇 到 不 懂 的 函数 、 对 象 和 其 他 语法 ， 可 参考 官网 文 
档 https://docs.helm.sh ° 


11.5.3 ”再 次 实践 MySQL chart 


学 习 了 chart 结 构 和 模板 的 知识 后 ， 现 在 重新 实践 一 次 MySQL chart, fH 
信 会 有 更 多 收获 。 


1. chart 安 装 前 的 准备 


作为 准备 工作 ， 安 装 之 前 需要 先 清楚 chart 的 使 用 方法 。 这 些 信 息 通 常 
记录 在 E a README.md 中 。 除 了 下 载 源 文件 查看 ， 执 行 
helm inspect values 可 能 是 更 方便 的 方法 ， 如 图 11-29 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ helm inspect values stable/mysql 
## mysql image version 

## ref: https://hub.docker.com/r/library/mysql/tags/ 
## 

image: "mysql" 

imageTag: "5.7.14" 


## Specify password for root user 
## 
## Default: random 10 character string 


# mysqlRootPassword: testing 


## Create a database user 
## 

# mysqlUser: 

# mysqlPassword: 


## Allow unauthenticated access, uncomment to enable 
## 
# mysqlAllowEmptyPassword: true 


图 11-29 


输出 的 AVE o pa BET BERT n] EL RIDE MySQL chart 
支持 哪些 参数 ， 安 装 之 前 需要 做 哪些 准备 。 其 中 有 一 部 分 是 天 于 存储 
的 ， 如 图 Mee ° 


persistence: 
enabled: true 
## database data Persistent Volume Storage Class 
## If defined, storageClassName: <storageClass> 
## If set to "-", storageClassName: "", which disables dynamic provisioning 
## If undefined (the default) or set to null, no storageClassName spec is 
## set, choosing the default provisioner. (gp2 on AWS, standard on 
GKE, AWS & OpenStack) 


# storageClass: "-" 
accessMode: ReadWriteOnce 
size: 8Gi 


图 11-30 


chart 定 义 了 一 个 PersistentVolumeClaim ， 申 请 8GB 的 PersistentVolume。 
由 于 我 们 的 实验 环境 不 文 持 动态 供给 ， 因 此 要 预先 创建 好 相应 的 PV， 
其 配置 文件 mysql-pvyml 的 内 容 如 图 11-31 所 示 。 


apiVersion: v1 
kind: PersistentVolume 
metadata: 
name: mysqLl-pv 
spec: 
accessModes: 
- ReadWriteOnce 


capacity: 
storage: 8Gi 
persistentVolumeReclaimPolicy: 


nfs: 
path: /nfsdata/mysql-pv 
server: 192.168.56.105 


图 11-31 


创建 PY mysql-pv， 如 图 11-32 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl apply -f mysql-pv.yml 
persistentvolume "mysql-pv" created 
ubuntu@k8s-master : ~$ 


ubuntu@k8s-master:~$ kubectl get pv 


NAME CAPACITY | ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS 
mysql-pv 8Gi RWO Retain Available 
ubuntu@k8s-master : ~$ 


图 11-32 
fe BORE] LAE chart T ° 
2. 定制 化 安装 chart 
除了 接受 values.yaml 的 默认 值 ， 我 们 还 可 以 定制 化 chart， 比 如 设置 


mysqlRootPassword ° 
Helm 有 两 种 方式 传递 配置 参数 : 


(1) 指定 自己 的 values 文 件 。 通 常 的 做 法 是 首先 通 HS inspect 
values mysql >myvalues.yaml Æ 成 values X fk , ARREA 
mysqlRootPassword , 最 Ja 1X fT helm dc m 
mysql ° 


(2) 通过 --set 直 接 传 入 参数 值 ， 如 图 11-33 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ helm install stable/mysql --set mysqlRootPassword=abc123 -n my 
NAME : my 

LAST DEPLOYED: Thu Oct 19 14:24:56 2017 

NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 

==> vi/Service 

NAME CLUSTER- IP EXTERNAL-IP PORTCS) AGE 
my-mysql 10.104.59.139 «none» 3306/TCP Qs 


==> vibetal/DepLloyment 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
my-mysql 1 1 1 0 0s 


==> vi/Secret 
NAME TYPE DATA AGE 
my-mysql Opaque 2 0s 


==> v1/PersistentVolumeClaim 
NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE 
my-mysql Pending Qs 


图 11-33 


mysqlRootPassword 设 置 为 abc123。 另 外 ，-n 设 置 release 为 my， 各 类 资 
源 的 名 称 即 为 my-mysql ° 


通过 helm list 和 helm status 可 以 查看 chart 的 最 新 状态 ， 如 图 11-34 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ helm list 

NAME REVISION UPDATED STATUS CHART NAMESPAC 
my 1 Thu Oct 19 14:24:56 2017 DEPLOYED mysql-0.3.0 default 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ helm status my 

LAST DEPLOYED: Thu Oct 19 14:24:56 2017 

NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 
==> vi1/Secret 
NAME TYPE DATA AGE 


my-mysql Opaque 2 8m 


==> vi/PersistentVolumeClaim 
NAME STATUS} VOLUME CAPACITY ACCESSMODES STORAGECLASS 
my-mysql | Boi mysql-pv 8Gi RWO 8m 


==> v1/Service 
NAME CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
my-mysql 10.104.59.139 <none> 3306/TCP 8m 


==> vlbeta1/Deployment 
NAME DESIRED CURRENT UP-TO-DATE 
my-mysql 1 1 1 


图 11-34 


PVC 已 经 Bound，Deployment 也 变 为 AVAILABLE 。 


11.5.4 ”升级 和 回 湾 release 


release 发 布 后 可 以 执行 helm upgrade 对 其 进行 升级 ， 通 过 --values 或 --set 
应 用 新 的 配置 。 比 如 将 当前 的 MySQL 版 本 升级 到 5.7.15， 如 图 11-35 所 


修 ° 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ helm upgrade --set imageTag=5.7.15 my stable/mysq 
Release "my" has been upgraded. Happy Helming! 

LAST DEPLOYED: Thu Oct 19 14:37:46 2017 

NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 

==> vi/Secret 

NAME TYPE DATA AGE 
my-mysql Opaque 2 12m 


==> v1/PersistentVoLumeCLaim 
NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS 
my-mysql Bound  mysql-pv 8Gi RWO 12m 


==> v1/Service 
NAME CLUSTER-IP EXTERNAL-IP  PORT(S) AGE 
my-mysql 10.104.59.139 <none> 33@6/TCP 12m 


==> vibetal/Deployment 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
my-mysql 1 1 1 0 12m 


图 11-35 


等 待 一 些 时 间 ， 升 级 成 功 ， 如 图 11-36 所 示 。 


UDU UKO 
ubuntuék8s- mius vs kubectl get deployment my-mysql -o wide 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINER(S) 


my-mysql 1 1 1 1 5m my-mysqL 
ubuntu@k8s-master : ~$ 


图 11-36 


helm history 可 以 查看 release 所 有 的 版 本 。 通 过 helm rollback 可 以 回 深 到 
任何 版 本 ， 如 图 11-37 所 示 。 


ubuntuék8s-master:-$ helm history my 

REVISION UPDATED STATUS 

1 Thu Oct 19 11:18:55 2017 SUPERSEDED 
2 Thu Oct 19 11:20:01 2017 DEPLOYED 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ helm rollback my 1 
Rollback was a success! Happy Helming! 
ubuntu@k8s-master: ~$ 


图 11-37 


回 滚 成 功 ，MySQL 恢 复 到 5.7.14， 如 图 11-38 所 示 。 


ubuntu@k8s-master:~$ helm history my 
REVISION UPDATED STATUS DESCRIPTION 
Thu Oct 19 11:18:55 2017 SUPERSEDED Ss ie Install complete 


Thu Oct 19 11:20:01 2017 SUPERSEDED eo Upgrade complete 
Thu Oct 19 11:27:01 2017 DEPLOYED dex Rollback to 1 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ kubectl get deployment my-mysql -o wide 


DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERCS) | IMAGE(S 
1 1 8m my-mysql mysql:5.7.14 


图 11-38 


11.5.5 ”开发 目 己 的 chart 


Kubernetes 给 我 们 提供 了 大 量 官方 chart， 不 过 要 部 署 微服 务 应 用 ， 还 
是 需要 开发 自己 的 chart， 下 面 就 来 实践 这 个 主题 


1. 创 建 chart 
执行 helm create mychart 命 令 ， 创 建 chart mychart， 如 图 11-39 所 示 。 


o 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ helm create mychart 
Creating mychart 
ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ tree mychart 
mychart 

| 一 charts 

I-— Chart.yaml 

| 一 templates 

| l— deployment. yam1 

| -一 _helpers.tpl 

| -一 ingress.yaml 

| F-- NOTES.txt 

| L— service. yaml 

L— values.yaml 


2 directories, 7 files 
ubuntuek8s -master : ~$ 


图 11-39 


Helm 会 帮 我 们 创建 目 永 mychart， 并 生成 各 类 chart 文 件 。 这 样 我 们 融 可 
以 在 此 基础 上 开发 目 己 的 chart 了 。 


新 建 的 chart 献 认 包 偏 一 个 nginx 应 用 示例 ，values.yaml 内 容 如 图 11-40 所 
ZN o 


# Default values for mychart. 
# This is a YAML-formatted file. 
# Declare variables to be passed into your templates. 
replicaCount 1 
image: 
repository: nginx 
tag: stable 
pullPolicy: IfNotPresent 
service: 
name: nginx 
type: ClusterIP 
externalPort: 80 
internalPort: 80 
ingress: 
enabled: false 
# Used to create an Ingress record. 
hosts: 
- chart-example. local 


图 11-40 


开发 时 建议 大 家 参考 官方 chart 中 的 模板 values.yaml、Chart.yaml， 里 面 
包含 了 大 量 最 佳 实践 和 最 常用 的 钞 数 、 流 控制 ， 这 里 就 不 一 一 展开 
2. 调试 chart 


只 要 是 程序 就 会 有 bug，chart 也 不 例外 。Helm 提 供 了 debug 的 工具 : 
helm lint 和 helm install --dry-run --debug ° 


helm lint 会 检测 chart 的 语法 ， 报 告 错 误 以 及 给 出 建议 。 


een D 如 图 11- 
41 所 示 。 


clare variables to be passed into your templates. 


# Decl 
replicaCount: 1 
image: 

repository: nginx 


tag: stable 
pullPolicy IfNotPresent 


service: 
name: nginx 
type: ClusterIP 
externalPort: 80 
internalPort: 80 


图 11-41 
helm lint mychart 会 指出 这 个 语法 错误 ， 如 图 11-42 所 示 。 
ubuntu@k8s-master: ~$ 


[INFO] Chart.yaml: icon is recommended 
[ERROR] values.yaml: unable to parse YAML 
error converting YAML to JSON: yaml: line 8: could not find expected ':' 


Error: 1 chart(s) linted, 1 chart(s) failed 
ubuntu@k8s-master : ~$ 


图 11-42 


mychart 目 孙 被 作为 参数 传递 给 helm lint。 错 误 修 复 后 则 能 通过 检测 , 
如 图 11-43 所 示 。 
ubuntu@k8s-master: ~$ 


ubuntu@k8s-master:~$ helm lint mychart 
==> Linting mychart 


[INFO] Chart.yaml: icon is recommended 


1 chart(s) linted, no failures 
ubuntuek8s-master : ~$ 


图 11-43 


helm install --dry-run --debug 会 模拟 安装 chart， 并 输出 每 个 模板 生成 的 
YAML 内 容 ， 如 图 11-44、 图 11-45 所 示 。 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ helm install --dry-run mychart --debug 
[debug] Created tunnel using local port: '46295' 


[debug] SERVER: "localhost:46295" 


[debug] Original chart version: 
[debug] CHART PATH: /home/ubuntu/mychart 


NAME : solitary-kudu 

REVISION: 1 

RELEASED: Fri Oct 20 09:59:51 2017 
CHART: mychart-0.1.0 

USER-SUPPLIED VALUES: 

{} 


COMPUTED VALUES: 
image: 
pullPolicy: IfNotPresent 
repository: nginx 
tag: stable 
ingress: 
annotations: null 
enabled: false 
hosts: 
- chart-example. local 
tls: null 
repLicaCount: 1 
resources: {} 
service: 
externalPort: 80 
internalPort: 8@ 
name: nginx 
type: ClusterIP 


HOOKS : 
MANIFEST: 


图 11-44 


# Source: mychart/templates/service.yaml 
apiVersion: v1 
kind: Service 
metadata: 
name: solitary-kudu-mychart 
labels: 
app: mychart 
chart: mychart-0.1.0 
release: solitary-kudu 
heritage: Tiller 
spec: 
type: ClusterIP 
ports: 
- port: 80 
targetPort: 80 
protocol: TCP 
name: nginx 
selector: 
app: mychart 
release: solitary-kudu 
# Source: mychart/templates/deployment.yaml 
apiVersion: extensions/vibetal 
kind: Deployment 
metadata: 
name: solitary-kudu-mychart 
labels: 
app: mychart 
chart: mychart-0.1.0 
release: solitary-kudu 
heritage: Tiller 
spec: 
replicas: 1 
template: 
metadata: 
labels: 
app: mychart 
release: solitary-kudu 
spec: 
containers: 
- name: mychart 
image: "nginx:stable" 
imagePullPolicy: IfNotPresent 
ports: 
- containerPort: 80 
livenessProbe: 
httpGet: 
path: / 
port: 80 
readinessProbe: 
httpGet: 
path: / 
port: 80 
resources: 


图 11-45 
我 们 可 以 检测 这 些 输出 ， 判 断 是 否 与 预期 相符 。 
同样 ，mychart 目 录 作 为 参数 传递 给 helm install --dry-run --debug ° 
3. 安装 chart 
当 我 们 准备 就 绪 ， 就 可 以 安装 chart 了。Helm 支 持 四 种 安装 方法 : 
(1) 安装 仓库 中 的 chart， 例 如 helm install stable/nginx ° 


4 


(2) 通过 tar 包 安装 ， 例 如 helm install /nginx-1.2.3.tgz ° 


(3) 通过 chart 本 地 目录 安装 ， 例 如 helm install /nginx 。 


s 


(4) 通过 URL 安 装 ， 例 如 helm install https://example.com/charts/nginx- 
1.2.3.tgz ° 


这 里 我 们 使 用 本 地 目 永 安装， 如 岁 11-46 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ helm install mychart 
NAME: opinionated-nightingale 

LAST DEPLOYED: Fri Oct 20 10:14:06 2017 
NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 


CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
opinionated-nightingale-mychart 10.100.28.221 <none> 80/TCP Qs 


==> vibetai/DepLoyment 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
opinionated-nightingale-mychart 1 1 1 0 0s 


NOTES: 
1. Get the application URL by running these commands: 
export POD.NAME-$(kubectl get pods --namespace default -l "appemychart,release-opi 


echo "Visit http://127.0.0.1:8080 to use your application" 
kubectl port-forward $POD. NAME 8080:80 


ubuntu&k8s master: ~$ 


图 11-46 


当 chart 部 署 到 Kubernetes 集 群 后 ， 便 可 以 对 其 进行 更 为 全 面 的 测试 
Te 

4. 将 chart 添 加 到 仓库 

chart 通 过 测试 后 可 以 添加 到 仓库 中 ， 团 队 其 他 成 员 就 能 够 使 用 了 。 任 
fi] HTTP Server 4b HJ DA Fd f/E chart C JÆ 9» F H 3E z& TE k8s-node1 
192.168.56.106 上 搭建 仓库 ° 


(1) 在 k8s-node1 上 启动 一 个 httpd 容 器 ， 如 图 11-47 所 示 。 


root@k8s-node1: ~# 
root@k8s-node1:~# mkdir /var/www 
root@k8s-node1:~# 


root@k8s-node1:~# docker run -d -p 8080:80 -v /var/www/:/usr/local/apache2/htdocs/ httpd 
f3d5f0779a04a3074bd332764263e0283d8548e8f9b2b96dc744e098b45ce075 
root@k8s-node1:~# 


图 11-47 


(2) 通过 helm package 将 mychart 打 包 ， 如 图 11-48 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ helm package mychart 

Successfully packaged chart and saved it to: /home/ubuntu/mychart-0.1.0.tgz 
ubuntu@k8s-master: ~$ 


图 11-48 


(3) 执行 helm repo index 生 成 仓库 的 index 文 件 ， 如 图 11-49 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ mkdir myrepo 
ubuntu@k8s-master:~$ mv mychart-0.1.0.tgz myrepo/ 


ubuntu@k8s-master:~$ helm repo index myrepo/ --url http://192.168.56.106:8080/charts 
ubuntu@k8s-master:~$ ls myrepo/ 

index.yaml  mychart-0.1.0.tgz 

ubuntuek8s-master : ~$ 


图 11-49 


Helm 会 扫描 myrepo 目 录 中 的 所 有 tgz 包 并 生成 index.yaml。--url 指 定 的 
是 新 仓库 的 访问 路 人 径 。 新 生成 的 index.yaml 记 录 了 当前 仓库 中 所 有 chart 
的 信息 ， 如 图 11-50 所 示 。 


apiVersion: v1 
entries: 


mychart: 

- apiVersion: v1 
created: 2017-10-21T16:39:39.184818935408:00 
description: A Helm chart for Kubernetes 


digest: ae8d7138002d432014dc8638ec37202823e9207445caf08a660d154b26e936ea 
name: mychart 
urls: 
- http://192.168.56.106:8080/charts/mychart-0.1.0.tgz 
version: 0.1.0 
generated: 2017-10-21T16:39:39.184265707+08 : 00 


图 11-50 
当前 只 有 mychart 这 一 个 chart ° 


( 4 ) 将 mychart-0.1.0.tgz 和 index.yaml 上 f£ 到 k8s-nodel 
的 /Var/www/charts 目 录 ， 如 图 11-51 所 示 。 


root@k8s-nodel :~# 

rootGk8s-node1:-£ ls /var/www/charts/ 
index.yaml  mychart-0.1.0.tgz 
root@k8&s-nodel1: ~# 


图 11-51 


(5) 通过 helm repo add 将 新 仓库 添加 到 Helm， 如 图 11-52 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ helm repo add newrepo http://192.168.56.106:8080/charts 
"newrepo" has been added to your repositories 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ helm repo list 


URL 
https://kubernetes-charts.storage.googleapis.com 
SUR Tage 0.0.1: spears 


图 11-52 
仓库 命名 为 newrepo，Helm 会 从 仓库 下 载 index.yaml。 
(6) 现在 已 经 可 以 repo search 到 mychart 了 ， 如 图 11-53 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ helm search mychart 
NAME VERSION DESCRIPTION 


local/mychart @.1.@ A Helm chart for Kubernetes 
newrepo/mychart 0.1.0 A Helm chart for Kubernetes 
ubuntu@k8s-master : ~$ 


图 11-53 


除了 newrepo/mychart， 这 里 还 有 一 个 local/mychart。 这 是 因为 在 执行 第 
2 步 打 包 操 作 的 同时 ，mychart 也 被 同步 到 了 local 的 仓库 。 


(7) 已 经 可 以 直接 从 新 仓库 安装 mychart 了 ， 如 图 11-54 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ helm install newrepo/mychart 
NAME: guilded-jellyfish 

LAST DEPLOYED: Sat Oct 21 16:49:31 2017 
NAMESPACE: default 

STATUS: DEPLOYED 


RESOURCES: 

==> vi/Service 

NAME CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
guilded-jellyfish-mychart 10.109.@.87 <none> 80/TCP Qs 


==> vibetal/DepLoyment 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
guilded-jellyfish-mychart 1 1 i 0 0s 


NOTES: 

1. Get the application URL by running these commands: 
export POD NAME-$(kubectl get pods --namespace default -1 "app=mychart,r 
echo "Visit http://127.0.0.1:8080 to use your application" 
kubectl port-forward $POD NAME 8080:80 


[11-54 


(8) 若 以 后 仓库 添加 了 新 的 chart， 则 需要 用 helm repo update 更 新 本 地 
的 index， 如 图 11-55 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ helm repo update 

Hang tight while we grab the latest from your chart repositories... 
...Skip local chart repository 


...Successfully got an update from the "newrepo" chart repository 
... Successfully got an update from the "stable" chart repository 
Update Complete. $ Happy Helming! $ 

ubuntuék8s -master : ~$ 


图 11-55 


这 个 操作 相当 于 Ubutun 的 apt-get update ° 


11.6 小结 
本 章 我 们 学 习 了 Kubernetes 包 管理 器 Helm。 


E * Wb ^ FRAR RRA 
DA 


Helm P?» Fl TillerARA ae ZA « BOP vin fi Echart, ARS gs fA 
管理 release。 

chart 是 Helm 的 应 用 打包 格式 ， 它 由 AACA 日 录 构 成 。 其 中 最 重要 
的 是 模板 ， 模 板 中 定义 了 Kubernetes 各 类 资源 的 配置 信息 ，Helm 在 周 

署 时 通过 values.yaml 实 例 化 模板 。 


Helm 人 允许 用 户 开 发 目 己 的 chart， 并 为 用 户 提供 了 调试 工具 。 用 户 可 以 
搭建 自己 的 chart 仔 库 ， 在 团队 中 共享 chart 。 


Helm #5 84 FA P? f£ Kubernetes 上 高 效 地 运行 和 管理 微服 务 架 构 应 用 ， 


Helm 非 常 重要 。 
第 12 章 ”网络 


本 章 我 们 讨论 Kubernetes 网 络 这 个 重要 主题 。 
Kubemetes 作 为 编排 引 敬 管理 着 分 布 在 不 同 广 点 上 的 容器 和 Pod © 
Pod、Service、 外 部 组 件 之 间 需 要 一 种 可 靠 的 方式 找到 彼此 并 进行 通 
信 ，Kubernetes 网 络 则 负责 提供 这 个 保障 。 本 章 包 括 如 下 内 容 : 

(1) Kubernetes 网 络 模 型 。 

(2) 各 种 网 络 方案 。 


(3) Network Policy ° 


12.1 Kubernetes 网 络 模 型 


Kubernetes 采 用 的 是 基于 遍 平 地 址 空间 的 网 络 模 型 ， 集 群 中 的 每 个 Pod 
都 有 目 己 的 IP 地 址 ，Pod 之 间 不 需要 配置 NAT 束 能 直接 通信 。 男 外 ， 同 
一 个 Pod 中 的 容器 共享 Pod 的 I[P， 能 够 通过 localhost 通 信 。 


这 种 网 络 模型 对 应 用 开发 者 和 管理 员 相 当 友 好 ， 应 用 可 以 非常 方便 地 
从 传统 网 络 迁 移 到 Kubernetes。 每 个 Pod 可 被 看 作 是 一 个 个 独立 的 系 
统 ， 而 Pod 中 的 容器 则 可 被 看 作 同 一 系统 中 的 不 同 进程 。 


下 面 讨论 在 这 个 网 络 模型 下 集群 中 的 各 种 实体 如 何 通信 。 知 识 点 前 面 
都 已 经 涉及 ， 这 里 可 当 作 复习 和 和 总结。 


1. Pod 内 容器 之 间 的 通信 


当 Pod 被 调度 到 某 个 斑点 ，Pod 中 的 所 有 容器 都 在 这 个 斑点 上 运行 ， 这 
些 容 右 共 译 相同 的 本 地 文件 系统 、IPC 和 网 络 命 名 空间 。 


不 同 Pod 之 间 不 存在 端口 冲突 的 问题 ， 因 为 每 个 Pod 都 有 目 己 的 全 地 
址 。 当 某 个 容 需 使 用 localhost 时 ， 意 味 着 使 用 的 是 容 禹 所 属 Pod 的 地 址 


空间 。 


比如 Pod A 有 两 个 容 絮 container-A1 和 container-A2，container-A1 在 端口 
1234 上 监听 ， 当 container-A2 连 接 到 localhost1234 时 ， 实 际 上 就 是 在 访 
问 container-A1。 这 不 会 与 同一 个 站 点 上 的 Pod B 冲 突 ， 即 使 Pod B 中 的 
ffs container-B 142, E I5 DT1234*m L1 ° 


2. Pod 之 间 的 通信 

Pod 的 IP 是 集群 可 见 的 ， 即 集群 中 的 任何 其 他 Pod 和 节点 都 可 以 通过 IP 
直接 与 Pod 通 信 ， 这 种 通信 不 需要 借助 任何 网 络 地 址 转换 、 隧 道 或 代 
理 技术 。Pod 内 部 和 外 部 使 用 的 是 同一 个 卫 ， 这 也 意味 着 标准 的 命名 服 
务 和 发 现 机 制 ， 比 如 DNS 可 以 直接 使 用 。 

3. Pod 与 Service 的 通信 


Pod 间 可 以 直接 通过 了 地 址 通信 ， 但 前 提 是 Pod 知 道 对 方 的 了 P。 在 
Kubernetes 集 群 中 ，Pod 可 能 会 频 和 营地 销毁 和 创建 ， 也 束 是 说 Pod 的 也 


不 是 固定 的 。 为 了 解决 这 个 问题 ，Service 提 供 了 访问 Pod 的 抽象 层 。 
无 论 后 端的 Pod 如 何 变化 ，Service 都 作为 稳定 的 前 端 对 外 提供 服务 o 
同时 ，Service 还 提供 了 高 可 用 和 负载 均衡 功能 ，Service 负 责 将 请 求 转 
发 给 正确 的 Pod。 


4. 外 部 访问 


无 论 是 Pod 的 IP 还 是 Service 的 Cluster IP， 它 们 只 能 在 Kubernetes 集 群 中 
可 见 ， 对 集群 之 外 的 世界 ， 这 些 IP 都 是 私有 的 。 


Kubemetes 提 供 了 两 种 方式 让 外 界 能 够 与 Pod 通 信 : 


e NodePort ° Service 通 过 Cluster 方 点 的 静态 端口 对 外 提供 服务 。 外 
部 可 以 通过 <NodeIP>:<NodePort> 访 问 Service ° 

。LoadBalancer。Service 利 用 cloud provider 提 供 的 load balancer 对 外 
提供 服务 ，cloud provider 负 责 将 load balancerH')ift = 5r [8] Service ° 
目前 支持 的 cloud provider 有 GCP、AWS、Azur 等 。 


12.2 各 种 网 络 方案 


网 络 模型 有 了 ， 如 何 实现 呢 ? 


为 了 保证 网 络 方案 的 标准 化 、 扩 展 性 和 灵活 性 ，Kubernetes 采 用 了 
Container Networking Interface (CNI) 规范 。 


CNI 是 由 CoreOS 提 出 的 容器 网 络 规范 ， 使 用 了 插件 (Plugin) 模型 创 
建 容 秀 的 网 络 栈 ， 如 图 12-1 所 示 。 


Container Network Interface (CNI) Drivers 


Container 
Runtime 


Container Network Interface (CNI) 


Loopback Bridge PTP MACvlan IPvlan 3rd-Party 
Plugin Plugin Plugin Plugin Plugin Plugin 


图 12-1 


CNI 的 优点 是 支持 多 种 容器 runtime， 不 仅仅 是 Docker。CNI 的 插件 模型 
支持 不 同 组 织 和 公司 开发 的 第 三 方 插 件 ， 这 对 运 维 人 员 来 说 很 有 吸引 
力 ， 可 以 灵活 选择 适合 的 网 络 方案 。 


目前 已 有 多 种 文 持 Kubernetes 的 网 络 方案 ， 比 如 Flannel、Calico ^ 
Canal ` Weave Net 等 。 因 为 它们 都 实现 了 CNI 规 范 ， 用 户 无 论 选 择 哪 种 
方案 ， 得 到 的 网 络 模型 都 一 样 ， 即 每 个 Pod 都 有 独立 的 卫 ， 可 以 直接 通 
言 。 区 别 在 于 不 同方 案 的 故 层 实现 不 同 ， 有 的 采用 基于 VxLAN 的 
Overlay 实 现 ， 有 的 则 是 Underlay， 性 能 上 有 区 别 。 再 有 就 是 是 否 支 持 
Network Policy ° 


12.3 Network Policy 


Network Policy 是 Kubernetes 的 一 种 资源 。Network Policy 通 过 Label 选 择 
Pod， 并 指定 其 他 Pod 或 外 界 如 何 与 这 些 Pod 通 信 。 


默认 情况 下 ， 所 有 Pod 是 非 陋 离 的 ， 即 任何 来 源 的 网 络 流量 都 能 够 访 
问 Pod， 没 有 任何 限制 。 当 为 Pod 定 义 了 Network Policy 时 ， 只 有 Policy 
人 允许 的 流量 才能 访问 Pod 。 


不 过 ， 不 是 所 有 的 Kubernetes 网 络 方案 都 文 持 Network Policy。 比 如 
Flannel 残 不 文 持 ，Calico 是 文 持 的 。 我 们 接 下 来 将 用 Canal 来 演示 


Network Policy ° Canal 这 个 开源 项 目 很 有 意思 ， 它 用 Flannel 实 现 
Kubernetes 集 群 网 络 ， 同 时 又 用 Calico 实 现 Network Policy ° 


12.3.1 部署 Canal 


部 署 Canal 与 部 署 其 他 Kubernetes 网 络 方案 非常 类 似 ， 都 是 在 执行 了 
kubeadm init 初 始 化 Kubernetes 集 群 之 后 通过 kubectl apply ZA TB DAY P 
络 方案 。 也 束 是 说 ， 没 有 太 好 的 办 法 直接 切换 使 用 不 同 的 网 络 方案 ， 
基本 上 只 能 重 狐 创建 集群 。 


要 销毁 当 前 集群 ， 最 简单 的 方法 是 在 每 个 斑点 上 执行 kubeadm reset, 
然后 就 可 以 按照 3.3.1 小 节 “ 初 始 化 Master" 中 的 方法 初始 化 集群 了 o 


kubeadm init --apiserver-advertise-address 192.168.56.105 


--pod-network-cidr=10.244.0.0/16 


然后 按照 文档 https://kubernetes.io/docs/setup/independent/create-cluster- 
kubeadnmy/ 安 装 Canal。 文 档 列 出 了 各 种 网 络 方案 的 安装 方法 ， 如 图 12-2 
所 示 。 


Choose one... Calico Canal Flannel Kube-router Romana Weave Net 


The official Canal set-up guide is here. 
Note: 
* For Canal to work correctly, --pod-network-cidr-10.244.0.0/16 has to be passed to kubeadm init. 


。 Canal works on amd64 only. 


kubectl apply -f https://raw.githubusercontent.com/projectcalico/canal/master/k8s-install/1.7 
kubectl apply -f https://raw.githubusercontent.com/projectcalico/canal/master/k8s-install/1.7 


图 12-2 
执行 如 下 命令 部 署 Canal: 
kubectl apply -f 


https://raw.githubusercontent.com/projectcalico/canal/master/k8 
s-install/1.7/rbac.yaml 


kubectl apply -f 


https://raw.githubusercontent.com/projectcalico/canal/master/k8 
s-install/1.7/canal.yaml 


部 署 成 功 后 ， 可 以 查看 到 Canal 相 关 组 件 ， 如 图 12-3 所 示 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get --namespace-kube-system daemonset canal 

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE 
canal 3 3 3 3 3 <none> 
ubuntu@k8s-master : ~$ 


o 


ubuntuék8s-master:-$ kubectl get --namespace=kube-system pod -o widelgrep canal 

canal-fkr18 3/3 Running 0 5d 192.168.56.107 . k8s-node2 
Running 0 5d 192.168.56.105 k8s-maste 
Running 0 5d 192.168.56.106 k8s-node1 


ubuntu@k8s-master : ~$ 
图 12-3 


Canal 作 为 DaemonSet 35 E $1 4 ^^ D si, JE T kube-system 这 个 
namespace ? 


12.3.2 ”实践 Network Policy 


为 了 演示 Network Policy， 我 们 先 部 署 一 个 httpd 应 用 ， 其 配置 文件 
httpd.yaml 如 图 12-4 所 示 。 


apiVersion: apps/vibetal 
kind: Deployment 
metadata: 
name: httpd 
spec: 
replicas: 
template: 
metadata: 
labels: 
run: httpd 
spec: 
containers: 
- name: httpd 
image: httpd:latest 
imagePullPolicy: IfNotPresent 
ports: 
- containerPort: 


apiVersion: v1 
kind: Service 
metadata: 

name: httpd-svc 


spec: 
type: NodePort 
selector: 
run: httpd 
ports: 

- protocol: TCP 
nodePort: 
port: 
targetPort: 


[& 12-4 


httpd 有 三 个 副本 ， 通 过 NodePort 类 型 的 Service 对 外 提供 服务 。 部 署 应 


用 ， 如 图 12-5 所 示 。 


ZR 


(1) 启动 一 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl apply -f httpd.yml 
deployment "httpd" created 

service "httpd-svc" created 

ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get pod -o wide 

NAME READY STATUS RESTARTS 
httpd-b5c6f48-gs7p2 1/1 Running 0 
httpd-b5c6f48-p86tv 1/1 Running 0 
httpd-b5c6f48-qxzxg 1/1 Running 0 
ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get service httpd-svc 
NAME TYPE CLUSTER-IP EXTERNAL-IP 
httpd-svc NodePort 10.104.77.239 «none» 
ubuntuek8s-master : ~$ 


图 12-5 


AGE IP 


NODE 


2m 10.244.1.7  k8s-nodel 
2m 10.244.1.8 k8s-node1 
2m 10.244.2.4 k8s-node2 


PORTCS) 
8080: 30000/TCP 


AGE 
2m 


当前 没有 定义 任何 Network Policy， 难 证 应 用 可 以 被 访问 ， 如 图 12-6 所 


o 


Pod ° 


ubuntuék8s -master : ~$ 


个 busybox Pod， 既 可 以 访问 Service， 


也 可 以 Ping 到 副本 


ubuntu@k8s-master:~$ kubectl run busybox --rm -ti --image=busybox /bin/sh 
If you don't see a command prompt, try pressing enter. 


/d 
/ € wget httpd-svc:8080 


Connecting to httpd-svc:8080 (10.104.77.239:8080) 


index.html 10096 | HERRERA kekok okokok okokeokekok oko KERR KEKE KE EK EEK HERE KEE EEK EERE 


mes 
/ # ping 10.244.1.7 
PING 10.244.1.7 (10.244.1.7): 56 data bytes 


64 bytes from 10.244.1.7: seq-0 ttl-62 time-1.696 ms 
64 bytes from 10.244.1.7: seq-1 ttl-62 time-0.558 ms 
64 bytes from 10.244.1.7: seq-2 ttl-62 time-0.497 ms 


图 12-6 


(2) 集群 节点 既 可 以 访问 Service， 也 可 以 Ping 到 副本 Pod， 如 图 12-7 


root@k8s-node2 :~# 


root@k8s-node2:~# curl 10.104.77.239:8080 
«html»«body»«hi»It works! </h1></body></htm1> 


root@k&8s-node2 :~# 


root@k8s-node2:~# ping -c 3 10.244.1.7 


PING 190.244.1.7 (10.244.1.7) 56(84) bytes of data. 
64 bytes from 10.244.1.7: icmp seq-1 ttl-63 time-0.487 ms 
64 bytes from 10.244.1.7: icmp seq-2 ttl-63 time-0.494 ms 
64 bytes from 10.244.1.7: icmp_seq=3 ttl-63 time-0.495 ms 


图 12-7 


(3) 集群 外 (192.168.56.1) 可 以 访问 Service， 如 图 12-8 所 示 。 


> ~ 
> ~ curl 192.168.56.106:30000 


<html><body><h1>It works! </h1></body></htm1> 
> ~ 


图 12-8 


现在 创建 Network Policy， 如 图 12-9 所 示 。 


kind: NetworkPolicy 
apiVersion: networking.k8s.io/v1 
metadata: 

name: access-httpd 
spec: 

podSelector: 

matchLabels : 
run: httpd 1 


matchLabels: 
access: 
ports: 
- protocol: TCP 


port: 


图 12-9 


@ 定义 将 此 Network Policy 中 的 访问 规则 应 用 于 label 为 ran: httpd 的 
Pod， 即 httpd 应 用 的 三 个 副本 Pod 。 


© ingress 中 定义 只 有 1label 为 access: "true" 的 Pod 才 能 访问 应 用 。 
© 只 能 访问 80 端 口 。 


通过 kubectl apply 创 建 Network Policy， 如 图 12-10 所 示 。 


ubuntu@k8s-master: ~$ 

ubuntuék8s-master:-$ kubectl apply -f policy.yaml 
networkpolicy "access-httpd" created 
ubuntu@k8s-master : ~$ 


ubuntuGk8s-master:-$ kubectl get networkpolicy 
NAME POD-SELECTOR AGE 

access-httpd run=httpd 32s 
ubuntu@k8s-master: ~$ 


图 12-10 
验证 Network Policy X: 


(1) busybox Pod 已 经 不 能 访问 Service， 如 图 12-11 所 示 。 


ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl run busybox --rm -ti --image=busybox /bin/sh 
If you don't see a command prompt, try pressing enter. 

/ # 

/ € wget httpd-svc:8080 --timeout=5 

Connecting to httpd-svc:8080 (10.104.77.239:8080) 

wget: download timed out 

/ # 


图 12-11 


如 果 Pod 添 加 了 1label access: "true" 就 能 访问 到 应 用 ， 但 Ping 已 经 被 禁 
止 ， 如 图 12-12 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl run busybox --rm -ti|--labels-" 

If you don't see a command prompt, try pressing enter 

/ # 

/ € wget httpd-svc: 8080 

Connecting to httpd-svc:8080 (10.104.77.239:8080) 

index.html 100% | EA A A A HH A A A HR RE KK RK EK RE EK | 
/ # 

/ # ping -c 3 10.244.1.7 

PING 10.244.1.7 (10.244.1.7): 56 data bytes 


--- 10.244.1.7 ping statistics --- 
3 packets transmitted, 0 packets received, 100% packet loss 


图 12-12 


(2) 集群 节点 已 经 不 能 访问 Service， 也 Ping 不 到 副本 Pod， 如 图 12-13 


root@k8s-node2 :~# 

root@k8s-node2:~# curl 10.104.77.239:8080 --connect-timeout 5 
curl: (28) Connection timed out after 5001 milliseconds 
root@k8s-node2 :~# 


root@k8s-node2:~# ping -c 3 10.244.1.7 
PING 10.244.1.7 (10.244.1.7) 56(84) bytes of data. 


--- 10.244.1.7 ping statistics --- 
3 packets transmitted, 0 received, 100% packet loss, time 1999ms 


图 12-13 


(3) 集群 外 (192.168.56.1) 已 经 不 能 访问 Service， 如 图 12-14 所 示 。 


> ~ 
> ~ curl 192.168.56.106:30000 --connect-timeout 5 
curl: (28) Connection timed out after 5003 milliseconds 
> ~ 


图 12-14 


如 果 希 望 让 集群 节点 和 集群 外 (192.168.56.1) 也 能 够 访问 到 应 用 ， 可 
以 对 Network Policy 做 如 图 12-15 所 示 的 修改 。 


kind: NetworkPolicy 
apiVersion: networking.k8s.io/v1 
metadata: 
name: access-httpd 
spec: 
podSelector: 
matchLabels : 
run: httpd 
ingress: 


- from: 
- podSelector: 
matchLabelLs: 


access: 


ports: 
- protocol: TCP 
port: 


图 12-15 


应 用 新 的 Network Policy， 如 图 12-16 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntuék8s-master:-$ kubectl apply -f policy.yaml 


networkpolicy "access-httpd" configured 
ubuntuék8s -master : ~$ 


图 12-16 


现在 ， 集 群 节点 和 集群 外 (192.168.56.3) 已 经 能 够 访问 了 ， 如 图 12- 
17、 图 12-18 所 示 。 


root@k8s-node2:~# 
root@k8s-node2:~# curl 10.104.77.239:8080 


«html»«body»«h1»It works! </h1></body></htm1> 
root@k8s-nodez2 : ~# 


图 12-17 


> ~ 
> ~ curl 192.168.56.106:30000 


<htmL><body><h1>It works! </h1></body></htm1> 
> ~ 


图 12-18 


除了 通过 ingress 限 制 进 入 的 流量 ， 也 可 以 用 egress 限 制 外 出 的 流量 。 大 
家 可 以 参考 官网 相关 文 要 和 示例 ， 这 里 职 不 发 述 了 


12.4 小结 


Kubernetes 采 用 的 是 局 平 化 的 网 络 模型 ， 每 个 Pod 都 有 目 己 的 IP， 并且 
可 以 直接 通信 


CNI 规 范 使 得 Kubernetes 可 以 灵活 选择 多 种 Plugin 实 现 集群 网 络 。 
Network Policy 赋 予 了 Kubernetes 强 大 的 网 络 访问 控制 机 制 。 


4313 Kubernetes Dashboard 


前 面 章 节 Kubemetes 所 有 的 探 作 我 们 都 是 通过 命令 行 工具 kubectl 完 成 
的 。 为 了 提供 更 丰富 的 用 户 体 验 ，Kubernetes 还 开发 了 一 个 基于 Web 的 
Dashboard， 用 户 可 以 用 Kubernetes Dashboard 部 署 容器 化 的 应 用 、 监 控 
应 用 的 状态 、 执 行 故 障 排 查 任务 以 及 管理 Kubernetes 的 各 种 资源 。 


在 Kubernetes Dashboard 中 可 以 查看 集群 中 应 用 的 运行 状态 ， 也 能 够 创 
建 和 修改 各 种 Kubernetes 资 源 ， 比 如 Deployment、Job、DaemonSet 
等 。 用 户 可 以 Scale Up/Down Deployment、 执 行 Rolling Update ^ Œ JA 
某 个 Pod 或 者 通过 辐 导 部 署 新 的 应 用 。Dashboard 能 显示 集群 中 各 种 资 
源 的 状态 以 及 日 志 信 息 。 


可 以 说 ，Kubernetes Dashboard 提 供 了 kubectl 的 绝 大 部 分 功能 ， 大 家 可 
以 根据 情况 进行 选择 。 


13.1 ”安装 


Kubernetes 默 认 没有 部 署 Dashboard， 可 通过 如 下 命令 安装 : 


kubectl create - 
f https://raw.githubusercontent.com/kubernetes/dashboard/master 
/src/deploy/recommended/kubernetes-dashboard.yaml 


Dashboard 会 在 kube-system namespace 中 创建 自己 的 Deployment 和 
Service， 如 图 13-1 所 示 。 


ubuntuék8s-master:-$ kubectl --namespace-kube-system get deployment kubernetes-dashboard 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 
1 


kubernetes-dashboard 1 1 1 17h 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl --namespace-kube-system get service kubernetes-dashboard 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORTCS) AGE 


kubernetes-dashboard ClusterIP 100.110.199.111 <none> 443/TCP 17h 


图 13-1 


为 Service 是 ClusterIP 类 型 ， 为 了 方便 使 用 ， 我 们 可 通过 kubectl] -- 


namespace=kube-system edit service kubernetes-dashboard 修改 成 


NodePort 类 型 ， 如 图 13-2 所 示 。 


spec: 
clusterIP: 10.110.199.111 
ports: 
- port: 
protocol: TCP 
targetPort: 


selector: 
k8s-app: kubernetes-dashboard 


sessionAffinity: None 
type: NodePort 
status: 


loadBalancer: {} 


图 13-2 


保存 修改 ， 此 时 已 经 为 Service 分 配 了 端口 31614， 如 图 13-3 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl --namespace-kube-system get service kubernetes-dash| 


NAME TYPE CLUSTER-IP EXTERNAL-IP PORTCS 


kubernetes-dashboard NodePort 10.110.199.111 <none> 443 :31614/TCP 
ubuntu@k8s-master : ~$ 


图 13-3 


通过 浏览 器 访问 Dashboard https:/192.168.56.105:31614/， 登 录 界 面 如 


图 13-4 所 示 。 


Kubernetes Dashboard 


Authentication method: 
@ Kubeconfig 


O Token 


Kubeconfig YAML file* 


SIGN IN SKIP 


图 13-4 


13.2 ”配置 登录 权限 


Dashboard 支 持 Kubeconfig 和 Token 两 种 认证 方式 ， 为 了 人 简化 配置 ， 我 
们 通过 配置 文件 dashboard-admin.yaml 为 Dashboard 默 认 用 户 赋予 admin 
权限 ， 如 图 13-5 所 示 。 


apiVersion: rbac.authorization.k8s.io/vibetal 
kind: ClusterRoleBinding 
metadata: 

name: kubernetes-dashboard 


labels: 
k8s-app: kubernetes-dashboard 
roleRef: 


apiGroup: rbac.authorization.k8s.io 
kind: ClusterRole 
name: cLuster-admin 

subjects: 

- kind: ServiceAccount 
name: kubernetes-dashboard 
namespace: kube-system 


图 13-5 


执行 kubectl apply 使 之 生效 ， 如 图 13-6 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl apply -f dashboard-admin.yaml 


clusterrolebinding "kubernetes-dashboard" created 
ubuntu@k8s-master: ~$ 


图 13-6 


现在 直接 单 击 登录 页 面 中 的 SKIP 束 可 以 进入 Dashboard 了 ， 如 图 13-7 所 
不 。 


kubernetes Q Search 


= Overview 


Cluster 
Services 
Namespaces 
Nodes Name $ Labels Cluster IP Internal endpoints 
Persistent Volumes component: apiserver kubernetes:443 TCP 
o9 kubernetes 10.96.0.1 2 
Roles provider: kubernetes kubernetes:0 TCP 
Storage Classes 
Secrets 
Namespace 
default Name $ Type 
OENAR default-token-cx5xr kubernetes.io/service-account-token 


Workloads 
Daemon Sets 
Deployments 
Jobs 
Pods 
Replica Sets 
Replication Controllers 
Stateful Sets 
Discovery and Load Balancing 


Ingresses 


图 13-7 


13.3 Dashboard 界 面 结构 
Dashboard 的 界面 很 测 洛 ， 分 为 三 个 大 的 区 域 。 


(1) 顶部 操作 区 ， 如 图 13-8 所 示 。 在 这 里 用 户 可 以 搜索 集群 中 的 资 
源 、 创 建 资 源 或 退出 。 


kubernetes Q Search + CREATE | ow 


图 13-8 


(2) 左边 导航 染 单 。 通 过 导航 染 单 可 以 查看 和 管理 集群 中 的 各 种 资 
源 。 有 表单 项 按照 资源 的 层级 分 为 以 下 两 类 : 


e Cluster 级 别 的 资源 ， 如 图 13-9 所 示 。 


Cluster 


Namespaces 
Nodes 

Persistent Volumes 
Roles 


Storage Classes 


图 13-9 


e Namespace 级 别 的 资源 ， 如 图 13-10 所 示 。 


Namespace 


default 


Overview 


Workloads 


Daemon Sets 
Deployments 

Jobs 

Pods 

Replica Sets 
Replication Controllers 


Stateful Sets 
Discovery and Load Balancing 


Ingresses 


Services 
Config and Storage 


Config Maps 
Persistent Volume Claims 


Secrets 


图 13-10 


默认 显示 的 是 default Namespace， 可 以 进行 切换 ， 如 图 13-11 所 示 。 


(3) 中 间 主 体 区 
在 导航 菜单 中 单 击 了 某 类 资源 ， 中 间 主 体 区 束 会 显示 


例 ， 比 如 单 击 Pods， 


Pods 


9990000000880 


Name > 


kubernetes-dashboard-747c4f7cf-wwlz7 


kube-proxy-jch75 
kube-flannel-ds-f7wgk 
kube-flannel-ds-Injqt 
kube-proxy-9cggh 
kube-flannel-ds-bgclx 
kube-apiserver-k8s-master 
kube-scheduler-k8s-master 
etcd-k8s-master 
kube-controller-manager-k8s-master 
kube-dns-545bc4bfd4-6zr5w 


kube-proxy-q6j8m 


All namespaces 


NAMESPACES 


default 


kube-public 


kube-system 


图 13-11 


如 图 13-12 所 示 。 


Node Status $ 
k8s-node1 Running 
k8s-node1 Running 
k8s-node1 Running 
k8s-node2 Running 
k8s-node2 Running 
k8s-master Running 
k8s-master Running 
k8s-master Running 
k8s-master Running 
k8s-master Running 
k8s-master Running 
k8s-master Running 


图 13-12 


Restarts 


^ 


Age $ 


18 hours 


18 hours 


18 hours 


18 hours 


18 hours 


18 hours 


18 hours 


18 hours 


18 hours 


18 hours 


18 hours 


18 hours 


13.4 ”典型 使 用 场景 


接 下 来 我 们 介绍 几 个 Dashboard 的 典型 使 用 场景 。 


13.4.1 XP Deployment 
单 击 顶 部 操作 区 的 +-CREATE 按 钮 ， 如 图 13-13 所 示 。 


Deploy a Containerized App 


© Specify app details below 


© Upload a YAML or JSON file 


1 


None 
v SHOW ADVANCED OPTIONS 


DEPLOY CANCEL 


图 13-13 
用 户 可 以 直接 输入 要 部 署 应 用 的 名 字 、 镜 像 、 副 本 数 等 信息 ， 也 可 以 


上 传 YAML 配 置 文件 。 如 果 是 上 传 配置 文件 ， 则 可 以 创建 任意 类 型 的 
资源 ， 而 不 仅仅 是 Deployment ° 


13.4.2 ”在线 操作 


对 于 每 种 资产， 都 可 以 单 击 按钮 执行 各 种 操作 ， 如 岁 13-14 所 示 。 


Deployments 


Name $ Namespace Labels Age * Images 


© kubernetes-dashboard kube-system k8s-app: kubernetes-das.. 18 hours gcr.io/google containers/k 


gcr.io/google containe 
@ kubedns kube-system k8s-app: kube-dns 18 hours gcr.io/google_containe Scale 
gcr.io/google containe 


Delete 


View/edit YAML| 


13-14 


例如 ， 单 击 View/edit YAML ， 可 直接 修改 资源 的 配置 ， 保 存 后 立即 生 
效 ， 其 效果 与 kubect edit 一 样 ， 如 图 13-15 所 示 。 


Edit a Deployment 


powered by ace 


1 

2 "kind": "Deployment", 

3 "apiVersion": "extensions/vlbetal", 

4 "metadata": { 

5 "name": "kube-dns", 

6 "namespace": "kube-system", 

d "selfLink": "/apis/extensions/vlbetal/namespaces/kube-system 
/deployments/kube-dns", 

8 "uid": "a676a020-c2c9-11e7-abb6-0800274451ad", 

9 "resourceVersion": "33294", 

10 "generation": 1, 

"bte "creationTimestamp": "2017-11-06T08:08:192", 

12+ "labels": { 

13 "k8s-app": "kube-dns" 

14 ) 

15+ "annotations": { 

16 "deployment .kubernetes.io/revision": "1" 

17 H 

18 - 

19+ "spec": { 

20 "replicas": 1, 

21+ "selector": { 

22» "matchLabels": { 

23 "k8s-app": "kube-dns" 

24 } 

25 be 

26+ "template": { 

27+ "metadata": { 

28 "creationTimestamp": null, 

29 * "labels": { 


CANCEL COPY UPDATE 


图 13-15 


13.43 ”查看 资源 详细 信息 


单 击 某 个 资源 实例 的 名 字 ， 可 以 查看 详细 信息 ， 其 效果 与 kubectl 
describe 一 样 ， 如 图 13-16 所 示 。 


Details 


Name: kube-dns 

Namespace: kube-system 

Labels: k8s-app: kube-dns 

Selector: k8s-app: kube-dns 

Strategy: RollingUpdate 

Min ready seconds: 0 

Revision history limit: Not set 

Rolling update strategy: Max surge: 10%, Max unavailable: 0 


Status: 1 updated, 1 total, 1 available, 0 unavailable 
Status 
New Replica Set 


Name Namespace Labels Pods Age Images 


k8s-app: kube-dns gcr.io/google_containers/k 
eo kube-dns-545bc4bfd4 kube-system 1/1 18 hours gcr.io/google. containers/k 
pod-template-hash: 101... gcr.io/google. containers/k 


Old Replica Sets 


There is nothing to display here 


图 13-16 


13.44 查看 Pod 日 志 


在 Pod 及 其 父 资源 (DaemonSet、ReplicaSet 等 ) 页 面 单 击 三 按钮 ， 可 
以 查看 Pod 的 日 志 ， 其 效果 与 kubectl logs 一 样 ， 如 图 13-17 所 示 。 


Logs from kube-flannel 


- 639451 Pss of default interface 
. 648318 kube-flannel-ds-f /wgk name enp@s3 and address 
- 640365 address to interface add 
- 658718 kube-flannel-ds-Injqt bde controller to sync 
.650800 manager 

-651546 kube.go:137] Node controller syne successful 

651575 main.go:235] Created subnet manager: Kubernetes Subnet Ma 
.651580 main.go:238] Installing signal handlers 

.651795 main.go:348] Found network config - Backend type: vxlan 
-651863 vxlan.go:119] VXLAN config: VNI=1 Port=@ GBP-false DirectR 
.659647 1 main.go:295] Wrote subnet file to /run/flannel/subnet.env 
-659714 main.go:299] Running backend. 

.659781 main.go:317] Waiting for all goroutines to exit 

.659815 vxlan_network.go:56] watching for new subnet leases 


Logs from 11/6/17 8:09 AM to 11/6/17 8:09 AM 


图 13-17 
Kubernetes Dashboard 界 面 设计 友好 ， 目 解释 性 强 ， 可 以 看 作 GUI 版 的 
kubectl， 更 多 功能 留 给 大 家 自己 探索 。 


135 小结 


本 章 介 绍 了 Kubernetes Dashboard 的 安装 和 使 用 方法 。Dashboard 能 完成 
日 常 管理 的 大 部 分 工作 ， 可 以 作为 命令 行 工 具 kubectl] 的 有 益 补 充 。 


第 14 章 ”Kubernetes 集 群 监控 


创建 Kubernetes 集 群 并 部 署 容 絮 化 应 用 只 是 第 一 步 。 一 旦 集群 运行 起 
来 ， 我 们 需要 确保 集群 一 起 都 是 正常 的 ， 所 有 必要 组 件 就 位 并 各 司 其 
只 ， 有 足够 的 资源 满足 应 用 的 需求 。Kubernetes 是 一 个 复杂 系统 ， 运 
维 团 队 需 要 有 一 套 工具 大 助 他 们 获知 集群 的 实时 状态 ， 并 为 故障 排查 
提供 及 时 和 谁 确 的 数据 文 持 。 


本 章 重 点 讨论 Kubernetes 销 用 的 监控 方案 ， 下 一 章 会 讨论 日 志 管 理 。 


14.1 Weave Scope 


Weave Scope 是 Docker 和 Kubernetes 可 视 化 监控 工具 。Scope 提 供 了 自 上 
而 下 的 集群 基础 设施 和 应 用 的 完整 视图 ， 用 户 可 以 轻松 对 分 布 式 的 容 
需 化 应 用 进行 实时 监控 和 问题 诊断 。 


14.1.1 ”安装 Scope 
安装 Scope 的 方法 很 简单 ， 执 行 如 下 命令 : 
kubectl apply --namespace kube-system 


f "https://cloud.weave.works/k8s/scope.yaml1?k8s- 
version-$(kubectl version | base64 | tr -d '\n')" 


部 署 成 功 后 ， 有 如 图 14-1 所 示 的 相关 组 件 。 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace-kube-system daemonset weave-scope-agen 
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELH 
weave-scope-agent 3 E] E] E] 3 <none> 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace-kube-system deployment weave-scope-app 
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 

weave-scope-app 1 1 1 T 18h 

ubuntuék8s master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace-kube-system service weave-scope-app 
NAME TYPE CLUSTER-IP EXTERNAL-IP — PORT(S) AGE 
weave-scope-app NodePort 10.106.149.68 <none> 80: 30693/TCP 18h 
ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get --namespace=kube-system pod | grep weave 
weave-scope-agent-765g2 1/1 Running 0 18h 
weave-scope-agent-nchjr 1/1 Running 0 18h 
weave-scope-agent-wnzn4 1/1 Running 0 18h 
weave-scope-app-567cfdb6d5-kk2cg 1/1 Running @ 18h 
ubuntu@k8s-master : ~$ 


图 14-1 


y 


(1) DaemonSet weave-scope-agent， 集 群 每 个 节点 上 都 会 运行 的 scope 


agent 程 序 ， 负 责 收集 数据 。 


(2) Deployment weave-scope-app ，scope 应 用 ， 从 agent 获 取 数 据 ， 通 
过 Web UI 展示 并 与 用 户 交 互 。 


(3) Service weave-scope-app， 默 认 是 ClusterIP 类 型 ， 为 了 方便 ， 已 通 
过 kubectl edit 修 改 为 NodePort ° 


14.1.2 ”使 用 Scope 


浏览 器 访问 http:/192.168.56.106:30693/，Scope 默 认 显示 当前 所 有 的 
Controller (Deployment、DaemonSet 等 ) ， 如 图 14-2 所 示 。 


e e J g Weave Scope x \ + 
€| © = 192.168.56.106:30693 Œ Q Search 
€ weavescope Q SEARCH PROCESSES ^ CONTAINERS PODS HOSTS “GRAPH Œ TABLE 
BY NAME BY DNS NAME CONTROLLERS WEAVE NET CPU Memory 
BY IMAGE SERVICES 
e e © 
kube-dns kube-flannel-ds kube-proxy 
Deployment of 1 pod DaemonSet of 3 pods DaemonSet of 3 pods 
o e e 
kubernetes-dashboa.. weave-scope-agent weave-scope-app 
Deployment of 1 pod DaemonSet of 3 pods Deployment of 1 pod 
6 NODES (4 FILTERED) 
Show Unmanaged Hide Unmanaged 


default ^ kube-system All Namespaces 


图 14-2 


1. 拓扑 结构 


Scope 会 目 动 构 建 应 用 和 集群 的 逻辑 拓扑 ， 比 如 单 击 项 部 PODS ， 
示 所 有 Pod 以 及 Pod 之 间 的 依赖 天 系 ， 如 图 14-3 所 示 。 


VERSION 1.6.5 ON weave-scope 


A 
Z 


显 


Weave Scope 


iet. v 


+ 


Æ ) © | 192168.56.106:30693/#!/state/{"controlPipe":null,"nodeDetails":[],"topologyViewMode":"topo","pinnedMetricType":null,"pinnedSear @ | Q Search 
4£ weavescope Q SEARCH PROCESSES ^ CONTAINERS | PODS HOSTS GRAPH = TABLE 
BY NAME BY DNS NAME CONTROLLERS WEAVENET CPU Memory 
BY IMAGE SERVICES 
FN R gx EN = 
[e ) e ( e) (e H . ( +) C y C 
E Wp 4 d J v 
kubescheduerküs.. kube-proxy-c6j8m.— weave scopeagent... kube-lanreldsi7w... kube-flannél-ds-Injgt weavecopeagert.. kubecontlerman. kube proxyjch75 — kubemetesdzshboa. kube proxy Seggh 
quem came fed imi er pic: ue necs peu pin pede 
RO ood 
a AÁ 
二: (Y a 
NE 
eee 
ee 
hup d 
pene 
oy 
/ 
labedoeSetbelbf. kube anra dobgeke 
S ERES 
. ° 
eave soopeagent.. weaveecapeapp 5- 
ee ipsc 
16 NODES (4 FILTERED) 
Show Unmanaged ^ Hide Unmanaged 
default ^ kube-system — AllNamespaces VERSION 1.6.5 ON Weave-scope-app-567cfdb6ds-kk2cg 


会 显示 


单 击 HOSTS， 


图 14-3 


各 个 市 点 之 间 的 关系 ， 如 图 14-4 所 示 。 


PROCESSES CONTAINERS PODS HOSTS 
BY NAME BY DNS NAME CONTROLLERS WEAVE NET 


BY IMAGE SERVICES 


5.15% 


k8s-node1 


5.20% } 


k8s-node2 
A 
Y y 
P 


10.41% 


k8s-master 


The Internet 


图 14-4 
2. 实时 资源 监控 
可 以 在 Scope 中 查看 资源 的 CPU 和 内 存 使 用 情况 ， 如 图 14-5 所 示 。 


CPU X Memory 


图 14-5 


支持 的 资源 有 Host、Pod 和 Container， 如 图 14-6、 图 14-7 所 示 。 


353.5MB 
k8s-node1 


viis 7MB 


d 


783.3MB 
Es 


k8s-master 


The Internet 
Outbound connections 


图 14-6 


0.33% 


XN 
etcd-k8s-master 
1 container 


0.69% 


kube-apiserver- 


k8s-master 
1 container 


图 14-7 
3. 在 线 操作 


Scope 还 提供 了 便捷 的 在 线 操作 功能 ， 比 如 选中 某 个 Host， 单 击 >_ TETH 
可 以 直接 在 浏览 右 中 打开 市 点 的 命令 行 终 疾 ， 如 图 14-8 所 示 。 


© [Wp weave Scope - k&s-master + 
192.168.56.106:3 state, "raw":true, e weut nro 
% weavescope Q SEARCH PROCESSES CONTAINERS PODS HOSTS GRAPH TABLE lal RESOURC > LIVE f 


BY NAME BY DNS NAME CONTROLL 


CPU R 
BY IMAGE 


rootek8s-master:/# su - ubuntu 
wubuntuék8s-master:-$ 

ubuntu&kBs-master:-$ kubectl get nodes 

NAME STATUS ROLES AGE VERSION 
kes-master Ready master 24 v1.8.1 
k8s-nodel Ready <none> 24 v1.8.1 
k8s-node2 Ready <none> — 2d v1.8.1 
ubuntuék8s-master:-$ M 


LOAD(1M) 


KERNEL VERSION: 4,4.0-98-generic #121-Ubuntu SMP Tu... 
UPTIME: 10h13m40s 


i ORT v# 
k8s-master 2379 62 
k8s-master 10255 15 
k8s-master 6443 11 
k8s-node1 6443 5 
k@o-nodo2 6442 4 
k8s-master 2379 62 
k8s-master 10255 15 


图 14-8 


单 击 Deployment 的 + 可 以 执行 Scale Up 操作 ， 如 图 14-9 所 示 。 


kubernetes-dashboard 


- 


STATUS 


0.00 % 33.4 MB 


CPU MEMORY 


INFO 


TYPE: Deployment 
NAMESPACE: kube-system 
CREATED: 3 days ago 
OBSERVED GEN.: 5 
DESIRED REPLICAS: 1 
3t PODS: 1 
STRATEGY: RollingUpdate 


PODS STATE # IP 
kubernetes-dashbo... Running 1 10.244.2.3 


CONTAINERS v CPU MEMORY 

kubernetes-dashboard 0.00% | 33.4 MB 

PROCESSES PID v CPU MEMORY 

Idachhnard 9091 n nn 9. 20 R MR 
图 14-9 


查看 Pod 的 日 志 ， 如 图 14-10 所 示 。 


© 好 weave scope -etcdkes " 
192.168.56.106.3c€ 
7 weavescope Q SEARCH RO 


2017-11-09701:47:37.6085951342 2017-11-09 0 7.608422 
(took 838.99148) 
2017-11-09701:47143.5405393842 
925ma for 1 entriea] 


2017-11-09701:47:43.5406069842 


2017-11-09 01:47:43.540242 


2017-11-09 01:47:43,540263 
ete range! 

2017-11-09101:52 
2017-11-09701:52 


37.6114601792 2017-11-09 
37.611492261z 2017-11-09 


7.610313 
7.611149 
(took 599.34445) 
2017-11-09701:57:37.6154125252 
2017-11-09701:57:37.615441132 
took 766.652p8) 
2017-11-09702:02:37.6216172052 2017-11-09 02 
2017-11-09702:02:37.6216430492 2017-11-09 02 
(took 1.004655ms) 
2017-11-09702:07237.623725647% 2017-11-09 02 
2017-11-09702:07:37.6248401892 2017-11-09 02 
mem 

2017-11-09702:12137.628508032 2017-11-09 0; 1.628217 1 | 
2017-11-09702:12:37.6295704512 2017-11-09 02:12:37.629386 1 
(took 742.77548) 
2017-11-09002:17:37. 
2017-11-09102:17:37. 
(took 810.493p8) 
2017-11-09702:22:37.637647662 2017-11-09 0: 
2017-11-09702:22:37.6387561612 2017-11-09 02:2 
(took 644.826ys) 


2017-11-09 
2017-11-09 0. 


7.614172 1 
7237.615226 1 | 


19913 
37.621258 


7.623263 
7.624528 


0247352 2017-11-09 02:17:37.633778 T 
3944892 2017-11-09 02:17:37.634924 1 


2.637475 1 | 
7.638648 I 


finished scheduled compaction at 120261 


etcdserver: apply entries took too long (10.31 


etcdserver: avoid queries with large range/del 


mvce: store.index: compact 120650 


mvec: finished scheduled compaction at 120650 


mvcet store.index: compact 121040 


mee: 121040 ( 


finished scheduled compaction at 


mvcc: store.in compact 121430 
mvce: finished scheduled compaction at 121430 
t: Running 

mvce: store.index: compact 121819 和 
mvcc: finished scheduled compaction at 121819 

# CONTAINERS: 1 
myce: store.index: compact 122210 naa. Kabsepétinm 
mvcc: finished scheduled compaction at 122210 ATED: 3 days ago 

ART: 1 
mvcc: store.index: compact 122599 
mvcc: finished scheduled compaction at 122599 
kube apiaerver k8a mas 


mvcc: store.index: compact 122988 


finished scheduled compaction at 122988 


zeU +O i 


182.3 MB 


MEMORY 
2379 54 
2379 6 
2379 6 


可 以 查看 attach ` restart ^ sto 
图 14-11 所 示 。 


图 14-10 


， 以 及 直接 在 Scope 


TX HH 


pear 


排查 问题 ， 如 


kubedns 


google_containers/k8s-d... k8s-master 
kube-dns-545bc4bfd4-62... 


cocum 


STATUS 


28 MB 


MEMORY 


IMAGE: gcr.io/google_containers/k8s-dns-kub... 
COMMAND: /kube-dns —domain=cluster.local. -dn... 
STATE: Up 19 hours 
UPTIME: 19h42m55s 
RESTART #: O 
NETWORKS: none 
IPS: 
PORTS: 
CREATED: 20 hours ago 


PROCESSES PID vCPU MEMORY 
/kube-dns 3613 0.00% 22.3MB 


图 14-11 


4. 强大 的 搜索 功能 


Scope 支 持 关 键 字 搜索 和 定位 资源 ， 如 图 14-12 所 示 。 还 可 以 进行 条 件 
搜索 ， 比 如 查找 和 定位 MEMORY 大 于 100MB 的 Pod， 如 图 14-13 所 示 ° 


Q prox | PROCESSES | | CONTAINERS | | PODS | HosTs «GRAPH TABLE 
one da CE BY NAME BY DNS NAME CONTROLLERS WEAVE NET CPU X Memory 
enter to apply the search as a | BY IMAGE SERVICES 
filter. 
e e e 
kube-proxy-q6j8m kube-proxy-ch75 kube-proxy-Seggh 
ee =a å O mum POTE 
图 14-12 
| Q MEMORY > 100M | PROCESSES CONTAINERS PODS HOSTS 
Try “etcd-k8s-mas’, BY NAME BY DNS NAME CONTROLLERS WEAVE NET 
"state:running", or "cpu > 2%". Hit 
enter to apply the search as a BY IMAGE SERVICES 
filter. 
102.7MB 
weave-scope- 


agent-765g2 
1 container 


如、 
246.9MB 


kube-apiserver-k8s-... 
1 container 


container 


图 14-13 


Scope 界 面 极其 友好 ， 操 作 简 洁 流 畅 ， 更 多 功能 留 给 大 家 去 探 


14.2 Heapster 


Heapster 是 Kubernetes 原 生 的 集群 监控 方案 。Heapster 以 Pod 的 形式 运 
行 ， 它 会 和 目 动 发 现 集群 和 节点， 从 节点 上 的 Kubelet 获 取 监 控 数 据 。 
Kubelet 则 是 从 节点 上 的 cAdvisor 收 集 数 据 。 


Heapster 将 数据 按照 Pod 进 行 分 组 ， 将 它们 存储 到 预先 配置 的 backend 并 
进行 可 视 化 展示 。 Heapster 当 前 支持 的 backend 有 InfluxDB (通过 
Grafana 展 示 ) ^ Google Cloud Monitoring 等 。Heapster 的 整体 架构 如 图 
14-14 所 示 。 


图 14-14 


下 面 我 们 将 实践 由 Heapster、InfluxDB 和 Grafana 组 成 的 监控 方案 。 
Kubelet 和 cAdvisor 是 Kubernetes 的 自 市 组 件 ， 无 须 额 外 部 署 。 


14.2.1 部 署 


Heapster 本 吴 是 一 个 Kubernetes 应 用 ， 部 署 方法 很 和 滑 单 ， 运 行 如 下 命 
AM 
T: 


git clone https://github.com/kubernetes/heapster.git 
kubectl apply -f heapster/deploy/kube-config/influxdb/ 


kubectl apply -f heapster/deploy/kube-config/rbac/heapster - 
rbac.yaml 


Heapster 相 关 资 源 如 图 14-15 所 示 。 


ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get 
heapster 1 
monitoring-grafana T 
monitoring-influxdb 1 
ubuntu@k8s-master : ~$ 
ubuntuek8s-master:-$ kubectl get 
heapster ClusterIP 
monitoring-grafana NodePort 
monitoring-influxdb ClusterIP 
ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get 
heapster-5d67855584-5hdqn 


monitoring-grafana-5bccc9f786-5bbkw 
monitoring-influxdb-85cb4985d4-t2b26 


ubuntu@k8s-master : ~$ 


为 了 便于 访问 ， 已 通过 kubectl edit 将 Service monitoring-grafana 的 类 型 


修改 为 NodePort 。 


14.2.2 ”使 用 


Wy HE 


iil 


Heapster 已 经 预先 配置 好 了 Grafana 的 DataSource 和 Dashboard , 


16 所 示 。 


Grafana - Home 


192.168.56.105 


€ 


Loy ZZ Home- & 


Getting Started with Grafana 
© 


Install-Grafana 


Starred dashboards 


Recently viewed dashboards 


--namespace=kube-system deployment | grep -e heapster -e monitor 
8m 
al 8m 
1 8m 


--namespace-kube-system service | grep -e heapster -e monitor 
10.108.228.4 <none> 80/TCP 
10.111.8.115 «none» 80:32314/TCP 
10.99.44.147 <none> 8086/TCP 


--namespace=kube-system pod -o wide | grep -e heapster -e monitor 
Running 8m 10.244.1.18 
Running 0 8m 10.244.2.13 


TZ Running 0 8m 10.244.2.14 


图 14-15 


览 器 打开 Grafana 的 Web UI: http://192.168.56.105:32314/ ° 


Home Dashboard 


Create your first data source 


图 14-16 


k8s-node2 
k8s-node1 
k8s-nodel1 


如 图 14- 


Create your first dashboard 


单 击 左上 角 的 Home 有 菜单 ， 可 以 看 到 预定 义 的 Dashboard Cluster #1 
Pods， 如 图 14-17 所 示 。 


(9 * Q,  Finddashboards by name 


| @ Home 


| ss Cluster 


ss Pods 


图 14-17 


单 击 Cluster， 可 以 查看 集群 中 节点 的 CPU、 内 存 、 网 络 和 和 位 盘 的 使 用 
情况 ， 如 图 14-18 所 示 。 


e vA 


Grafana - Cluster + 


€ 192.168.56.105:32314/dashboard/db/cluster?orgld-1 e 
49- quais ü 
nodename k8s-master ~ 


Overall Cluster CPU Usage 


Millicores 


0 
09:32 09:34 09:36 


= Usage = Limit = Request 


CPU Usage by Node 
350 


300 
250 
200 
150 


Millicores 


100 
50 


0 
09:32 09:34 09:36 09:38 09:40 09:42 09:44 09:46 09:48 
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在 左上 角 可 以 切换 查看 不 同市 点 的 数据 ， 如 图 14-19 所 示 。 
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图 14-19 


切换 到 Pods Dashboard， 可 以 查看 Pod 的 监控 数据 ， 包 括 单个 Pod 的 
CPU、 内 存 、 网 络 和 磁 一 使 用 情况 ， 如 图 14-20 所 示 。 
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在 左上 角 可 以 切换 到 不 同 Namespace 的 Pod， 如 图 14-21 所 示 。 
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Heapster 预 定义 的 Dashboard 很 直观 ， 也 很 简单 。 如 有 必要 ， 可 以 在 
Grafana 中 定义 自己 的 Dashboard， 满 足 特定 的 业务 需求 。 


14.3 Prometheus Operator 


前 面 我 们 介绍 了 Kubernetes 的 两 种 监控 方案 ， 即 Weave Scope 和 
Heapster， 它 们 主要 的 监控 对 象 是 Node 和 Pod。 这 些 数 据 对 Kubernetes 
运 维 人 员 是 必需 的 ， 但 还 不 够 。 我 们 通常 还 希望 监控 集群 本 身 的 运行 
状态 ， 比 如 Kubernetes 的 API Server ` Scheduler ^ Controller Manager 等 
管理 组 件 是 否 正 常 工作 以 及 负荷 是 否 过 大 等 。 


本 六 我 们 将 学 习 监 控 方 案 Prometheus Operator， 它 能 回答 上 面 这 些 问 
ATT 5 
题 


Prometheus Operator 是 CoreOS 开 发 的 基于 Prometheus 的 Kubernetes 监 控 
方案 ,也 可 能 是 目前 功能 最 全 面 的 开源 方案 。 我 们 先 通 过 截图 了 解 一 
FERETI A 


Prometheus Operator 通 过 Grafana 展 示 监 控 数 据 ， 预 定义 了 一 系列 的 
Dashboard， 如 图 14-22 所 示 。 
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e Kubemnetes 集 群 的 整体 健康 状态 如 图 14-23 所 示 。 
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。 整个 集群 的 资源 使 用 情况 如 图 14-24、 图 14-25 所 示 。 
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。 Kubernetes 各 个 管理 组 件 的 状态 如 图 14-26、 图 14-27 所 示 。 
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资源 使 用 情况 如 图 14-28 所 示 。 
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。 Deployment 的 运行 状态 如 图 14-29 所 示 。 
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Pod 的 运行 状态 如 图 14-30 所 示 。 
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这 些 Dashboard 展 示 了 从 集群 到 Pod 的 运行 状况 ， 能 够 帮助 用 户 更 好 地 
运 维 Kubernetes， 而 且 Prometheus Operator 迭 代 非 常 快 ， 相 信 会 继续 开 
发 出 更 多 更 好 的 功能 ， 所 以 值得 我 们 花 些 时 间 学 习 和 实践 。 


14.3.1 ” Prometheus 架构 


为 Prometheus Operator 是 基于 Prometheus 的 ， 所 以 我 们 需要 先 了 解 一 
F Prometheus ° 


Prometheus 是 一 个 非常 优秀 的 监控 工具 。 准 确 地 说 应 该 是 监控 方案 。 
Prometheus 提 供 了 数据 搜集 、 存 储 、 人 处理 、 可 视 化 和 告警 一 套 完 整 的 


解决 方案 。Prometheus 的 架构 如 图 14-31 所 示 。 
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官网 上 的 原始 以 构 图 比 上 面 这 张 要 复杂 一 些 ， 为 了 避免 注意 力 分 散 ， 
这 里 只 保留 了 最 重要 的 组 件 。 


1. Prometheus Server 


Prometheus Server 人 负责 从 Exporter 拉 取 和 存储 监控 数据 ， 并 提供 一 套 灵 
活 的 查询 语言 (PromQL) 供用 户 使 用 。 


2. Exporter 


Exporter 负 责 收集 目标 对 象 (host、container 等 ) 的 性 能 数据 ， 并 通过 
HTTP 接 口供 Prometheus Server 获 取 。 


3. 可 视 化 组 件 


监控 数据 的 可 视 化 展现 对 于 监控 方案 至 关 重 要 。 以 前 Prometheus 目 己 
开发 了 一 套 工 具 ， 不 过 后 来 废弃 了 ， 因 为 开源 社区 出 现 了 更 为 优秀 的 
产品 Grafana。Grafana 能 够 与 Prometheus 无 颖 集成 ， 提 供 完 美的 数据 展 
示 能 力 。 


4. Alertmanager 


用 户 可 以 定义 基于 监控 数据 的 告警 规则 ， 规 则 会 触发 告警 。 一 旦 
Alermanager 收 到 告警 ， 就 会 通过 预定 义 的 方式 发 出 告警 通知 ， 支 持 的 


方式 包括 Email、PagerDuty、Webhook 等 。 


14.3.2 Prometheus Operator 架 构 


Prometheus Operator 的 目标 是 尽 可 能 简化 在 Kubernetes 中 部 署 和 维护 
Prometheus 的 工作 。 其 架构 如 图 14-32 所 示 。 
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14-32 中 的 每 一 个 对 象 都 是 Kubernetes 中 运行 的 资源 。 
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1. Operator 


Operator 即 Prometheus Operator ， 在 Kubernetes 中 以 Deployment 运 行 。 
其 职责 是 部 署 和 管理 Prometheus Server， 根 据 ServiceMonitor 动 态 更 新 


Prometheus Server 的 监控 对 象 。 


2. Prometheus Server 


Prometheus Server 会 作为 Kubernetes 应 用 部 署 到 集群 中 。 为 了 更 好 地 在 
Kubemetes 中 管理 Prometheus，CoreOS 的 开发 人 员 专 门 定义 了 一 个 命名 


为 Prometheus 类 型 的 Kubernetes 定 制 化 资源 。 我 们 可 以 把 Prometheus 看 
作 一 种 特殊 的 Deployment， 它 的 用 途 就 RAI 3E Prometheus Server ° 


3. Service 


这 里 的 Service 束 是 Cluster 中 的 Service 资 源 ， 也 是 Prometheus 要 监控 的 
象 ， 在 Prometheus 中 叫 作 Target ° 每 个 监控 对 象 都 有 一 个 对 应 的 
Service。 比 如 要 监控 Kubernetes zs SLE —T 5 Schedule? 
应 的 Service。 当 然 ，Kubernetes 集 群 默认 是 没有 这 个 Service 的 , 
Prometheus Operator 会 负责 创建 。 


4. Service Monitor 


Operator E 87 5) zx E XTi Prometheus HJ Target 9!) Æ, ServiceMonitor Wi ze 

Target 的 抽象 。 比 如 想 监 控 Kubernetes Scheduler， 用 户 可 以 创建 一 个 与 

Scheduler Service 相 映射 的 ServiceMonitor 对 象 。Operator 则 会 发 现 这 个 

An ServiceMonitor， 并 将 Scheduler 的 Target 添 加 到 Prometheus 的 监控 列 
中 o 


ServiceMonitor 也 是 Prometheus Operator 专 门 开发 的 一 种 Kubernetes 定 制 
化 资源 类 型 。 


5. Alertmanager 


除了 Prometheus 和 ServiceMonitor，Alertmanager 是 Operator 开 发 的 第 二 


种 Kubernetes 定 制 化 资源 。 我 们 可 以 把 Alertmanager 看 作 一 种 特殊 的 
Deployment， 它 的 用 途 就 是 专门 部 署 Alertmanager 组 件 。 


14.3.3 ”部署 Prometheus Operator 


笔者 在 实践 时 使 用 的 是 Prometheus Operator 最 新 版 本 v0.14.0。 由 于 项 目 
开发 达 代 速度 很 快 ， 部 署 方 法 可 能 会 更 新 ， 必 要 时 请 参考 官方 文档 。 


1. 下 载 最 新 源码 


git clone https://github.com/coreos/prometheus-operator.git 


cd prometheus-operator 


为 方便 管理 ， 创 建 一 个 单独 的 Namespace monitoring, Prometheus 
Operator 相 关 的 组 件 都 会 部 署 到 这 个 Namespace。 


kubectl create namespace monitoring 
2. 安装 Prometheus Operator Deployment 


helm install --name prometheus-operator --set rbacEnable=true- - 
namespace=monitoring helm/prometheus-operator 


Prometheus Operator 所 有 的 组 件 都 打包 成 Helm Chart， 安 装 部 署 非常 方 
便 ， 如 图 14-33 所 示 。 如 果 对 Helm 不 熟悉 ， 可 以 参考 前 面相 关 的 章 
BE o 


ubuntu@k8s-master: ~$ 
ubuntu@k8s-master:~$ kubectl get --namespace-monitoring deployment prometheus-operator| 


NAME DESIRED CURRENT UP-TO-DATE AVAILABLE 
prometheus-operator-prometheus-operator 1 L i 1 
ubuntu@k8s-master: ~$ 


图 14-33 


3. 安装 Prometheus、Alertmanager 和 Grafana 


helm install --name prometheus -- 
set serviceMonitorsSelector .app=prometheus- - 
set ruleSelector.app-prometheus -- 


namespace-monitoring helm/prometheus 


helm install --name alertmanager -- 
namespace=monitoring helm/alertmanager 


helm install --name grafana --namespace=monitoring helm/grafana 


可 以 通过 kubect get prometheus 查 看 Prometheus 类 型 的 资源 ， 如 图 14-34 
所 示 。 


~$ 
~$ kubectl get --namespace=monitoring prometheus 


ubuntu@k8s-master: 
ubuntu@k8s-master : 
NAME AGE 
prometheus id 
ubuntu@k8s-master: 
ubuntuék8s-master : 
NAME 
prometheus-prometheus-0 
ubuntu@k8s-master : ~$ 
ubuntu@k8s-master:~$ kubectl get --namespace-monitoring service prometheus-prometheus 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
prometheus-prometheus NodePort 10.96.207.169 <none> 9090:30413/TCP 1d 
ubuntu@k8s-master :~$ 


~$ 

~$ kubectl get --namespace=monitoring pod prometheus-prometheus-0 
READY STATUS RESTARTS AGE 

2/2 Running 0 1d 


图 14-34 


ay 


为 了 方便 访问 Prometheus Server， 这 里 已 经 将 Service 类 型 通过 kubectl 


edit 改 为 NodePort ° 


同样 可 以 查看 Alertmanager 和 Grafana 的 相关 
所 示 。 


z 


v 
页 


源 ， 如 图 14-35、 图 14-36 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get --namespace=monitoring alertmanager 

NAME AGE 

alertmanager 2d 

ubuntu@k8s-master:~$ 

ubuntu@k8s-master:~$ kubectl get --namespace=monitoring pod alertmanager-alertmanager-0 
NAME READY STATUS RESTARTS AGE 
alertmanager-alertmanager-0 2/2 Running 0 2d 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace=monitoring service alertmanager-alertmanager 
NAME NPE CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
alertmanager-alertmanager NodePort 10.103.53.199 <none> 9093:32758/TCP 2d 
ubuntu@k8s-master : ~$ 


图 14-35 


ubuntu@k8s-master: 
ubuntu@k8s-master: 
NAME 
grafana-grafana 
ubuntu@k8s-master: 
ubuntu@k8s-master: 
NAME 


grafana-grafana-5fdf676c68-v7dlb 


ubuntu@k8s-master: 
ubuntu@k&8s-master : 
NAME 
grafana-grafana 
ubuntu@k8s-master: 


Service 类 型 也 都 已 


~$ 

~$ kubectl get --namespace=monitoring deployment grafana-grafana 
DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 

1 T 1 1 5h 

~$ 

~$ kubectl get --namespace=monitoring pod grafana-grafana-5fdf676c68-v7dlb 
READY STATUS RESTARTS AGE 

2/2 Running 0 5h 

~$ 

~$ kubectl get --namespace=monitoring service grafana-grafana 
TYPE CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
NodePort 10,109.107.156 <none> 80:32342/TCP 5h 

~$ 


图 14-36 


经 改 为 NodePort。 


4. 安装 kube-prometheus 


kube-prometheus 是 一 个 Helm Chart， 打 包 了 监控 Kubermetes 需 要 的 所 有 
Exporter 和 ServiceMonitor ° 


helm install --name kube-prometheus -- 
namespace=monitoring helm/kube-prometheus 


个 Exporter 会 对 应 一 个 Service ， 为 Pormetheus 提 供 Kubernetes 集 群 的 


各 类 监控 数据 ， 如 图 14-37 所 示 。 


ubuntu@k8s-master:~$ 
ubuntu@k8s-master:~$ kubectl get --all-namespaces service 
NAMESPACE NAME TYPE: CLUSTER-IP EXTERNAL-IP PORTCS) 
default kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 
kube-system heapster ClusterIP 10.108.228.4 <none> 80/TCP 
dns = ClusterIP 10.96.0.10 <none> 53/UDP ,53/TC 
kube-prometheus-exporte ap ] ClusterIP None «none» 443/TCP 
|kube-system kube-prometheus-exporter-kube-controller-manager ClusterIP None <none> 10252/TCP 
|kube-system kube-prometheus-exporter-kube-dns ClusterIP None <none> 
|kube-system kube-prometheus-exporter-kube-etcd ClusterIP None <none> 4001/TCP 
kube-system ^ kube-prometheus-exporter-kube-scheduler ClusterIP None <none> 10251/TCP 
|kube-system — kubelet — —  &—" ^ à. i . J] ClusterIP None «none» 10250/TCP 
k k s-dashboard NodePort 10.110.199.111 «none» 443:31614/TC 
kube-system ^ monitoring-grafana NodePort 10.111.8.115 «none» 80:32314/TCP 
kube-system ^ monitoring-influxdb ClusterIP — 10.99.44.147 «none» 8086/TCP 
kube-system — tiller-deploy ClusterIP — 10.111.247.7 <none> 44134/TCP 
kube-system weave-scope-app NodePort 10.106.149.68 <none> 80: 30693/TCP 
monitoring alertmanager-alertmanager NodePort 10.103.53.199 «none» 9093:32758/T! 
monitoring alertmanager-operated ClusterIP None «none» 9093/TCP, 678. 
i i f f NodePort 10.109.107.156 <none> 80:32342/TCP 
kube-prometheus-exporter-kube-state ClusterIP 10.100.157.79 <none> 80/TCP 
k orter-node ClusterIP 10.106.108.197 <none> 9100/TCP 
monitoring prometheus-operated mmm ClusterIP None <none> 9090/TCP 
monitoring prometheus-prometheus NodePort 10.96.207.169 <none> 9090: 30413/T! 
ubuntuek8s-master:-$ 


图 14-37 


每 个 Service 对 应 一 个 ServiceMonitor， 组 成 Pormetheus 的 Target 列 表 ， 如 
图 14-38 所 示 ° 


ubuntu@k8s-master: ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace=monitoring servicemonitor 
NAME AGE 
alertmanager-alertmanager 2d 
kube-prometheus-exporter-kube-api 2d 
kube-prometheus-exporter-kube-controller-manager 2d 
kube-prometheus-exporter-kube-dns 2d 
kube-prometheus-exporter-kube-etcd 2d 
kube-prometheus-exporter-kube-scheduLer 2d 
kube-prometheus-exporter-kube-state 2d 
kube-prometheus-exporter-kubelets 2d 
kube-prometheus-exporter-kubernetes 2d 
kube-prometheus-exporter-node 2d 
prometheus-operator 2d 
prometheus-prometheus 1d 
ubuntuek8s-master : ~$ 


图 14-38 


与 Prometheus Operator 相 关 的 所 有 Pod 如 图 14-39 所 示 。 


ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get pods --namespace-monitoring -o wide 

NAME READY STATUS RESTARTS Ip 
alertmanager-alertmanager-® 2/2 Running @ 10.244.1.26 
grafana-grafana-5fdf676c68-v7dlb 2/2 Running 10.244.1.30 
kube-prometheus-exporter-kube-state-5ff8596498-lprrr 2/2 Running 10.244.2.31 


kube-prometheus-exporter-node-6hbj7 1/1 Running 192.168.56.106 
kube-prometheus-exporter-node-k59dm 1/1 Running 192 .168.56.107 
kube-prometheus-exporter-node-t4cns 1/1 Running 192.168.56.105 


prometheus-operator-prometheus-operator-597f678b79-94qvw 1/1 Running 10.244.2.27 
prometheus-prometheus-O 2/2 Running 10.244.2.32 
ubuntuek8s-master : -$. 


114-39 


NODE 
k8s-node2 
k8s-node2 
k8s-node1 
k8s-node1 
k8s-node2 
k8s-master 
k8s-node1 
k8s-nodel 


我 们 注意 到 有 些 Exporter 没 有 运行 Pod， 这 是 因为 像 API Server ^ 
Scheduler、Kubelet 等 Kubermetes 内 部 组 件 原生 就 支持 Prometheus， 只 需 


要 定义 Service 殉 能 直接 从 预定 义 症 口 获取 监控 数据 。 


通 过 D "o zs 打 开 Pormetheus Hj Web 
(http://192.168.56.105:30413/targets) ， 如 图 14-40 所 示 。 


= © © 192.168.56.105:30413/targets 


Targets 


alertmanager 
Endpoint State Labels 


kube-prometheus-exporter-kube-dns 


kube-prometheus-exporter-kube-state 


Endpoint State Labels 


http://10.244.2.31:8080/metrics uP 
kube-prometheus-exporter-node 
Endpoint State Labels 


图 14-40 
可 以 看 到 所 有 Target 的 状态 都 是 UP 。 
5. 安装 Alert 规 则 


http//10.244.1.26:9089/metrics TUP 


Endpoint State Labels 
http://10.244.1.21:10054/metrics UP endpoint="http-metrics-dnsmasq" pod="kube-dns-5 


http://10.244.1.21:10055/metrics (UP ET 


http://192.168.56.105:9100/metrics uP pod="kube-prometheus-exporte 


http//192.168.56.106:9100/metrics (UP bods "kube-promethous-exporte 


UI 


Prometheus Operator 提 供 了 默认 的 Alertmanager 告 警 规则 ， 通 过 如 下 命 
ATJE 
ITUR 


sed -ie 's/role: prometheus- 
rulefiles/app: prometheus/g' contrib/kube- 
prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 


sed - 
ie 's/prometheus: k8s/prometheus: prometheus/g' contrib/kube- 
prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 


sed -ie 's/job=\"kube-controller -manager/job=\"kube-prometheus- 
exporter-kube-controller-manager/g' contrib/kube- 
prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 


sed -ie 's/job=\"apiserver/job=\"kube-prometheus -exporter -kube- 
api/g' contrib/kube-prometheus/manifests/prometheus/prometheus - 
k8s-rules.yaml 


sed -ie 's/job=\"kube-scheduler/job=\"kube-prometheus-exporter - 
kube-scheduler/g' contrib/kube- 
prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 


sed -ie 's/job=\"node-exporter/job=\"kube-prometheus-exporter - 
node/g' contrib/kube- 
prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 


kubectl apply -n monitoring -f contrib/kube- 
prometheus/manifests/prometheus/prometheus-k8s-rules.yaml 


6. 安装 Grafana Dashboard 


Prometheus Operator 定 义 了 显示 监控 数据 的 默认 Dashboard， 通 过 如 下 
AERE 
MIRKA 


sed -ie 's/grafana-dashboards-0/grafana- 
grafana/g' contrib/kube-prometheus/manifests/grafana/grafana- 
dashboards. yaml 


sed -ie 's/prometheus-k8s.monitoring/prometheus- 
prometheus.monitoring/g' contrib/kube- 
prometheus/manifests/grafana/grafana-dashboards.yaml 


kubectl apply -n monitoring -f contrib/kube- 
prometheus/manifests/grafana/grafana-dashboards.yaml 


打开 Grafana 的 Web UI (http://192.168.56.105:32342/) ， 如 图 14-41 所 
ZN o 


G- 24 Home- & 


Home Dashboard 


Getting Started with Grafana 


© © 


Starred dashboards 


Recently viewed dashboards 
Pods 
Deployment 
Nodes 


Kubernetes Control Plane Status 


图 14-41 


Grafana 的 DataSource 和 Dashboard 已 目 动 配置 ， 单 击 Home 束 可 以 使 用 
我 们 在 最 开始 讨论 过 的 那些 Dashboard 了 ， 如 图 14-42 所 示 。 
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图 14-42 


14.4 小结 
本 章 我 们 实践 了 三 种 Kubernetes 监 探 方案 。 


(1) Weave Scope 可 以 展示 集群 和 应 用 的 完整 视图 。 其 出 色 的 交互 性 
让 用 户 能 够 轻松 对 容 右 化 应 用 进行 实时 监控 和 问题 诊断 。 


(2) Heapster 是 Kubernetes 原 生 的 集群 监控 方案 。 预 定义 的 Dashboard 
能 够 从 Cluster 和 Pods 两 个 层次 监控 Kubernetes。 


(3) Prometheus Operator 可 能 是 目前 功能 最 全 面 的 Kubernetes 开 源 监 
控 方案 。 除 了 能 够 监控 Node 和 Pod， 还 支持 集群 的 各 种 管理 组 件 ， 比 


如 API Server ` Scheduler ` Controller Manager 等 。 


Kubernetes 监 控 是 一 个 快速 发 展 的 领域 ， 随 着 Kubernetes 的 普及 ， 一 定 
会 清 现 出 更 多 的 优秀 方案 。 


第 15 章 ”Kubernetes 集 群 日 志 管 理 


Kubernetes 开 发 了 一 个 Elasticsearch 附 加 组 件 来 实现 集群 的 日 志 管 理 。 
这 是 Elasticsearch、Fluentd 和 Kibana 的 组 合 。Elasticsearch 是 一 个 搜索 引 
警 ， 负 责 存储 日 志 并 提供 查询 接口 ，Fluentd 负 责 从 Kubernetes 搜 集 日 


志 并 发 送 给 Elasticsearch; Kibana 提 供 了 一 个 web GUI， 用 户 可 以 浏览 
和 搜索 存储 在 Elasticsearch 中 的 日 志 ， 如 图 15-1 所 示 。 


kubernetes fluentd 


图 15-1 


15.1 部 署 


Elasticsearch 附 加 组 件 本 身 会 作为 Kubernetes 的 应 用 在 集群 里 运行 ， 其 
YAML 配 置 文 件 可 从 


https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/fluentd 
-elasticsearch 获 取 ， 如 图 15-2 所 示 。 


Branch: masterv kubernetes / cluster / addons / fluentd-elasticsearch / 


Pa k8s-merge-robot Merge pull request #55509 from tallclair/psp-addons = L 


lia es-image Merge pull request #54215 from mrahbar/elasticsearch logging. discovery 
lia fluentd-es-image Add CRI log format support in fluentd. 

lig podsecuritypolicies Add optional addon PSPs 

E OWNERS Added coffeepac to ElasticSearch owners 

E) README.md Refactored the fluentd-es addon files, moved the fluentd configuratio... 


E es-service.yaml Adds the new addon-manager labels on cluster addon templates 


=) es-statefulset.yaml fluentd-elasticsearch add-on: Rename Elasticsearch Docker image tag 
=) fluentd-es-configmap.yaml Fix CRI fluentd config. 


E] fluentd-es-ds.yaml Fix CRI fluentd config. 


=) kibana-deployment.yaml fluentd-elasticsearch add-on: Upgrade API versions 


=) kibana-service.yaml Adds the new addon-manager labels on cluster addon templates 


图 15-2 


可 将 这 些 YAML 文 件 下 载 到 本 地 目录 ， 比 如 addons， 通 过 kubect] apply 
-f addons/ 部 署 ， 如 图 15-3 所 示 。 


这 里 有 一 点 需要 注意 : 


ubuntuek8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl apply -f addons/ 
service "elasticsearch-Logging" created 
serviceaccount "elasticsearch-Logging" created 
clusterrole "elasticsearch-Logging" created 
clusterrolebinding "elasticsearch-logging" created 
statefulset "elasticsearch-Logging" created 


configmap "fluentd-es-config-v@.1.1" created 
serviceaccount "fluentd-es" created 
clusterrole "fluentd-es" created 
clusterrolebinding "fluentd-es" created 
daemonset "fluentd-es-v2.0.2" created 
deployment "kibana-Logging" created 

service "kibana-logging" created 
ubuntu@k8s-master: ~$ 


图 15-3 


后 面 我 们 会 通过 NodePort 访 问 Kibana，， 


需要 注 


释 挥 kibana-deployment. yaml 中 的 环境 变 量 SERVER_BASEPATH， 人 否则 
无 法 访问 ， 如 图 15-4 所 示 。 


所 有 的 资源 都 部 署 在 kube-system Namespace 里 ， 如 图 15-5 所 示 。 


spec: 


containers: 


- name: 


image: 


kibana-logging 
docker.elastic.co/kibana/kibana:5.6.2 


resources: 


limits: 
cpu: 1000m 
requests: 
cpu: 100m 


name: ELASTICSEARCH. URL 


value: http://elasticsearch-lo 


name : 


value: 
- name: XPACK SECURITY. ENABLED 
value: 


ports: 


- containerPort: 
name: ui 
protocol: TCP 


图 15-4 


ubuntuék8s-master:-$ kubectl get --namespace-kube-system daemonset fluentd-es-v2.0.2 
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR 
fluentd-es-v2.0.2 2 2 2 2 2 <none> 
ubuntu@k8s-master : ~$ 


ubuntuék8s-master:-$ kubectl get --namespace-kube-system pod -1 "k8s-app-fluentd-es" 
NAME READY STATUS RESTARTS AGE 

fluentd-es-v2.0.2-2hjp4 1/1 Running 0 9m 

fluentd-es-v2.0.2-m4gq7 1/1 Running 0 9m 

ubuntu@k8s-master : ~$ 


图 15-5 


DaemonSet fluentd-es 从 每 个 世 点 收集 日 志 ， 然 后 发 送 给 Elasticsearch ， 
如 图 15-6 所 示 。 


ubuntuék8s-master:-$ kubectl get --namespace-kube-system statefulset elasticsearch-logging 
NAME DESIRED CURRENT AGE 

elasticsearch-logging 2 2 13m 

ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace=kube-system pod -l "k8s-app-elasticsearch-logging" 
NAME READY STATUS RESTARTS AGE 


elasticsearch-1ogging-0 1/1 Running 0 13m 

elasticsearch-logging-1 1/1 Running 0 13m 

ubuntuék8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get --namespace-kube-system service elasticsearch-logging 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORTCS) AGE 
elasticsearch-logging NodePort 10.103.27.59 «none» 9200:32607/TCP 14m 
ubuntu@k8s-master :~$ 


图 15-6 


Elasticsearch 以 StatefulSet 资 源 运行 ， 并 通过 Service elasticsearch-logging 
对 外 提供 接口 。 这 里 已 经 将 Service 的 类 型 通过 kubectl edit 修 改 为 
NodePort ° 


可 通过 http://192.168.56.106:32607/ 验 证 Elasticsearch 已 正常 工作 ， 如 
15-7 所 示 。 


€ Œ © 192.168.56.106:32607 


name" : "elasticsearch-logging-1", 
"cluster name" : "kubernetes-logging", 
"cluster uuid" : "wRgkHHpNRGCtyQoSvpAIjA", 
"version" : ( 
"number" : "5.6.2", 
"build hash" : "57e20£3", 
"build date" : "2017-09-23T713:16:45.7032", 
"build snapshot" : false, 
"lucene version" : "6.6.1" 
}, 


"tagline" : "You Know, for Search" 


图 15-7 


Kibana 以 Deployment 资 源 运行 ， 用 户 可 通过 Service kibana-logging 访 问 
其 Web GUI。 这 里 已 经 将 Service 的 类 型 修改 为 NodePort， 如 图 15-8 所 
ZN o 


ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace=kube-system deployment kibana-logging 

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE 

kibana-logging 1 1 1 T 21m 

ubuntu@k8s-master : ~$ 

ubuntuék8s-master:-$ kubectl get --namespace=kube-system pod -1 "k8s-app-kibana-logging" 
NAME READY STATUS RESTARTS AGE 


kibana-lLogging-7879c88776-sfhnv 1/1 Running 0 21m 
ubuntu@k8s-master : ~$ 

ubuntu@k8s-master:~$ kubectl get --namespace-kube-system service kibana-logging 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
kibana-logging NodePort 10.103.43.140 <none> 5601:30319/TCP 21m 
ubuntu@k8s-master:~$ 


图 15-8 


通过 http://192.168.56.106:30319/ 访 问 Kibana， 如 图 15-9 所 示 。 


c | © 192.168.56.106:30319/app/kibana#/management/kibana/index?_g=() 


一 
Management / Kibana 
kibana 
© 


Index Patterns Saved Objects Reporting Advanced Settings 


Discover | warning | : a 
No default index pattern. You Configure an index pattern 


Visualize must select or create one to ; y 
contiade, In order to use Kibana you must configure at least one index p 


Dashboard against. They are also used to configure fields. 
Index pattern advanced options 
Timelion 

logstash-* 


Machine Learning 
Patterns allow you to define dynamic index names using * as a wildcard. 


Graph Time Filter field name @ refresh fields 


Dev Tools @timestamp 


Management Expand index pattern when searching [DEPRECATED] 


With this option selected, searches against any time-based index pattern| 
currently selected time range. 


Searching against the index pattern /ogstash-* will actually query Elastics} 


With recent changes to Elasticsearch, this option should no longer be neq 


Use event times to create index names [DEPRECATED] 


图 15-9 


Kibana 会 显示 Index Pattern 创 | 建 页 面 。 直 接 单 击 Create，Kibana 会 自动 
完成 后 续 配 置 ， 如 图 15-10 所 示 。 


Management / Kibana 


A kibana Index Patterns Saved Objects Reporting Advanced Settings 


Visualize 


* logstash-* 


This page lists every field in the logstash-* index and the field's associated core type as recorded 
type of each field, changing field types must be done using Elasticsearch's Mapping AP! % 


Dashboard 


Timelion 


Machine Learning fields (113) scripted fields (0) source filters (0) 


Graph Q Filter 


Dev Tools name = type format searchable @= 

Management @timestamp [5 date 
MESSAGE string 
MESSAGE.keyword string 
PRIORITY string 
PRIORITY. keyword string 
SYSLOG_FACILITY string 
SYSLOG_FACILITY. keyword string 
SYSLOG_IDENTIFIER string 
SYSLOG_IDENTIFIER.keyword string 


id string 


TIEF- EF EJ « [5S1 « [5 


.index string 
_score number 
_source _source 


_type string 
【< Collapse 


docker.container_id string 


图 15-10 


这 时 ， 单 击 左 上 角 的 Discover 就 可 以 查看 和 检索 Kubernetes 日 志 了 ， 如 
图 15-11 所 示 ° 


140 hits New Save Open Share Reporting €  Olasti5minutes > 
| Search... (e.g. status:200 AND extension:PHP) Uses lucene query syntax B 
Add a filter + 
November 20th 2017, 09:28:37.808 - November 20th 2017, 09:43:37.808— Auto + 
40 
Selected Fields (9 
30 
? source ¢ 
3 20 
$ 
Available Fields e 10 
D ETATE A =el dE Ce UC EET EH MIS I mm 
09:29:00 09:30:00 09:31:00 09:32:00 09:33:00 09:34:00 — 09: 09:36:00 — 09:37:00 09:38:00 09:39:00 09:40:00 09:41:00 09:42:00 09:43:00 
t iid Q @timestamp per 30 seconds 
t index Time - Source 
* score 
» November 20th 2017, 09:43:20.000 type: response timestamp: November 20th 2017, 09:43:20.000 tags: pid: 1 method: get 
t type statusCode: 200 req.uri: /api/reporting/jobs/list. completed. since?sinces2017-11-20T01X3A34X3A24 .35 
t docker.contaiter. Jd 8Z req.method: get req.headers.host: 192.168.56.106:30319 roq.headers.connection: keep-alive 


req.headers.accept: application/json, text/plain, */* req.headers.kbn-system-api: true 
xeq.headers.kbn-version: 5.6.2 req.headers.user-agent: Mozilla/5.@ (Macintosh; Intel Mac OS X 10.1 


t kubernetes.container... 


t kubernetes.host 
> November 20th 2017, 09:43:10.000 type: response @timestamp: November 20th 2017, 09:43:10.000 tags: pid: 1 method: get 
statusCode: 200 req.url: /api/reporting/jobs/list. completed since?sinces2017-11-20T01X3A34X3424 .35 
t kubernetes.labels.k8s... 8Z req.method: get req.headers.host: 192.168.56.106:30319 req.headers.connection: keep-alive 


t kubernetes/labels.con... 


t kubernetes.labels.ku... req.headers.accept: application/json, text/plain, */* req.headers.kbn-system-api: true 


req-headers.kbn-version: 5.6.2 req-headers.user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.1 
t kubernetes.labels.po.. 


t kubernetes.labels.task > November 20th 2017, 09:43:05.000 tog: [httpd] 10.244.2.101 - root [20/Nov/2017:01:43:05 +0000] "POST /write?consistency=&db=k8s&preci 
sion-&rp-defoult HTTP/1.1" 204 Q "-" "heapster/vl.4.0" 27012880-cd94-11e7-8365-000000000000 25607 


t kubernetes.labels.ver... 

stream: stderr docker.container id: 293164a3c9cdc518d770bd6eb9b0204e68ce413390dfc62f030996553754b1 
t kubernetes.master url 1b kubernetes.container name: influxdb kubernotes.namospace name: kube-system 
t kubernetes.namespa... Xubernetes.pod name: monitoring-influxdb-8Scb4985d4-68czc kubernetes.pod id: O684d6bb-cc75-11e7-94 


t kubernetes.pod id + November 20th 2017. 09:42:59.000 tunes renonce Atimestanp: Novemher 20th 2017. 09:47:59 POA tage nid: 1 methn oot 


图 15-11 


Kubermetes 日 志 管 理 系统 已 经 惑 绪 ， 用 户 可 以 根据 需要 创建 目 己 的 
Dashboard， 上 有 具体 方法 可 参考 Kibana 官 方 文档 。 


152 ”小 结 


Elasticsearch 附 加 组 件 本 号 会 作为 Kubernetes 的 应 用 在 集群 里 运行 ， 以 
实现 集群 的 日 志 管 理 。 它 是 Elasticsearch、Fluentd 和 Kibana 的 组 合 。 


Elasticsearch 是 一 个 搜索 引擎 ， 负 责 存储 日 志 并 提供 查询 接口 。 
Fluentd 负 责 从 Kubernetes 搜 集 日 志 并 发 送 给 Elasticsearch。 


Kibana 提 供 了 一 个 Web GUI， 用户 可 以 浏览 和 搜索 存储 在 Elasticsearch 


中 的 日 志 。 
写 在 最 后 


作为 Kubernetes 的 实战 教程 ， 我 们 已 经 到 了 该 收尾 的 时 候 。 


本 教程 润 盖 了 Kubernetes 最 最 重要 的 技术 : 集群 架构 、 容 器 化 应 用 部 
Æ ^ Scale Up/Down、 深 动 更 新 、 监 控 检 查 、 集 群 网 络 、 数 据 管 理 、 监 
控 和 日 志 管 理 ， 通 过 大 量 的 实验 探讨 了 Kubernetes 的 运行 机 制 。 


这 本 教程 的 目标 是 使 读者 能 够 掌握 实施 和 管理 Kubernetes 的 必需 技 
能 ， 能 够 真正 将 Kubernetes 用 起 来 。 


为 了 达到 这 个 目标 ， 每 一 章 都 设计 了 大 量 的 实践 操作 环节 ， 通 过 截图 
和 日 志 帮 助 读者 理解 各 个 技术 要 点 ， 同 时 为 读者 目 己 实践 Kubernetes 
提供 详尽 的 参考 。 

本 教程 对 读者 应 该 会 有 两 个 作用 : 


(1) FA n] 以 按照 章节 顺序 系统 地 学 习 Kubernetes， 并 通过 教程 中 
的 实验 掌握 Kubernetes 的 理论 知识 和 实 操 技 能 9 


(2) 有 经 验 的 运 维 人 员 可 以 将 本 教程 当 作 参考 材料 ， 在 实际 工作 中 有 
针对 性 地 碍 看 相关 知识 点 。 


硕 望 读者 能 够 通过 本 教程 打下 扎实 基础 ， 从 容 地 运 维 Kubernetes， 并 
结合 所 在 公司 和 组 织 的 实际 需求 搭建 出 实用 的 容器 管理 平台 。 


最 后 祝 大 家 使 用 Kubernetes 愉 快 ! 
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